Let’s say your association has a vision of creating a revenue-generating technology product. Maybe it’s a mobile app or a web application for your membership. Before you send out an RFP to software development firms to quote and build the product, there are four things to consider that will significantly impact the success of the product. We’ll get to those individually, but there is also one item that stands above the four and is something you need to always keep in mind as you move ahead. That one item is this: you are now a technology start-up!
What does that mean?
It means a major head-shift as to how you’ll plan, release, market, sell and improve the product. It means that regardless of whether your association has been around for a half-century, that you’re experts in your field or have thousands of members – your product will still be unknown and unproven to your customers. To make this product work, you’ll need to think and act like a start-up entrepreneur. I’ve been in the business of building software products for companies for 25 years and what I’ve seen is established companies who wish to create a value-added product often significantly underestimate the internal time and resources needed to be a successful technology start-up. Keeping that start-up mentality and energy in mind from the beginning (including writing a business plan) will be a tremendous help to both your product, and your process.
OK, with that out of the way, let’s talk about the four things.
Thing 1: Do you have a guinea pig client in place?
You don’t want to build your product in a vacuum where some coders build it and then you simply release it to the world. Instead, what I have seen work very well is when companies build the product for (and with) a small number of test customers. Get them recruited and on-board before coding even begins. In this scenario, you either provide them the product for free, or heavily discount the price. This will give you two critical things: feedback that the features and tools you’re creating are heading in the right direction, and (ideally) a great testimonial to use for PR in the end. This way, on day one that your product is finished you can then tell a success story, provide a reference, know that the product is focused on fulfilling a client-expressed need, and build a strong foundation for your sales efforts.
Thing 2: Minimal Viable Product
I’ve seen this time and time again: where one extraneous feature of the product ends up getting used 10% of the time by the product user, but that one feature cost 50% or more of the overall project cost to develop. The lesson to be learned is to start small. The version one release of your product should address the one thing it meant to solve. Ignore the rest for now. There will be time to add and improve later. Your customer’s feedback will guide you to properly prioritize and budget how the product will evolve as you continue.
Thing 3: It’s Never Done
We all know that technology changes, and more often than not it changes unexpectedly. Your product is going to be affected by these changes. It might be a policy change by Apple or Android, a new security vulnerability, an update to the operating system or device, a change in the coding architecture, the possibilities are endless and any one of these could cause major issues. Before you build the product – when you’re first developing your business plan and cost projections, plan for change. Not only external changes as I just described, but internal changes that come from you and customers. What you absolutely want to avoid is simply budgeting for the development of the initial product and saying, “Cool. It’s done!”
Thing 4: The Tech Support Time Sink
Oh, how often this one gets overlooked! You’ve released your product to the world, but who is going to support the users? True, you might have created documentation for them. Maybe even training videos. But, if you want happy customers (and especially as a start-up, you want happy customers!), they are going to need some level of tech support that will require a human touch – as well as time and resources. Ideally over time you’ll automate the process as you figure out where the support is needed, but early on you want that human contact to get feedback to improve the product. Will that support come for your technology provider or from your internal staff? Plan for the resources, cost and responsibilities early on.
These four things are by no means comprehensive (I thought of a half-dozen more when writing this article), but from personal experience and hard lessons learned over two decades, I truly believe they will help you along your Start-Up journey.