Stages in product development

More than just an idea. At this point you have defined the problem you will solve, who is the customer, what is your solution, and how it will be initially implemented (mobile app, desktop software, SaaS, etc.)  It’s not too early to start your product roadmap.

The best way to gather feedback from potential customers is to show, not tell. It’s also much cheaper to garner feedback before you start coding. Whether it’s drawing on sheets of paper, wireframes, PowerPoint slides, it doesn’t matter, so long as you are conveying the essence of what you plan to build – what it will do, for whom – and gathering valuable feedback from your target customers.

Once you are far enough along in your customer development process to be confident in investing in something more robust than a mockup, it’s time for a demo: whether software or hardware, unlike static mockups, your demo is dynamic – it changes based on inputs and/or commands. But keep in mind, demos are to be shown, not handed out to potential end users for them to try out. You are still in the show mode, only a demo should show a lot more of the human-computer interaction than a mockup. If you are raising capital a demo is your ante in the game. If for example, you have a complex multi-user game, a video can be an effective demo. Videos don’t crash and can do a good job of capturing your audiences’ attention and their imaginations.

It’s a huge leap from demo to prototype, perhaps the biggest you’ll make. Unlike demos, prototypes can and should be used by your potential customers, albeit with plenty of caveats. Prototypes are not feature/function complete, bug free, nor optimized for performance. But watching your prospective customers actually attempt to use your prototype to accomplish their goals will be one of the most powerful learning experiences you can have as a developer. If you can afford it, hiring a usability testing lab is an excellent investment at this stage, as you’ll learn more from this formal process than by gathering feedback in a haphazard way.

Alpha is perhaps the least used term for a stage of the product development process. It’s initial meaning was a version suitable for use only by the company – strictly an internal version, feature/function complete, but far from bug free or optimized for performance. UI changes might still need to be made. Often alphas get extended to other insiders for their feedback: investors, friends, and family. Today the term often is confused with an early version that’s not yet ready for a beta release.

The term beta has changed radically from the days of desktop software to today’s mobile and SaaS applications. Some products are in permanent beta. The term originally meant beta testing – an initial release usually to a limited subset of potential users to get feedback, discover bugs, and most importantly find out if there were any showstoppers on the way to a full, commercial release. Beta is a great disclaimer, the ultimate excuse for a “not ready for prime time” release. Today developers tend to rely on their beta users for the testing that was once done in house by quality assurance teams. Despite the changes in the meaning of beta, it’s still a major milestone in development. Once your product is released in beta there’s no turning back!

Minimum Viable Product came out of the agile programming movement.  The intent is to release a version with only enough features, function and UI polish to establish a beach head market with early adopters. The goal was to get feedback early and often and use that feedback to rapidly modify the product to improve product/market fit. It’s a real challenge to determine what goes into an MVP and what to leave out. But when it doubt, release it! With a couple of caveats: don’t lose or damage your users’ data, don’t plague them with constant crashes, and make sure performance is at least acceptable – users get less and less patient and expectations of responsiveness rise constantly.

Once the company has learned enough from its MVP to be willing to invest in a launch it’s time to press down the gas pedal on marketing and sales. As they say the best way to kill a bad product is to promote it well. So you need to make sure that you launch a version is robust: features, functions, UI, performance, interoperability, and so forth. You don’t get a second chance to make a first impression.

The product development cycle never ends, it just repeats itself. Given that the goal of a startup is to constantly learn and adapt, upgrades represent that Darwinian principle. Now that you are engaged with the market you can start adding features your users want and you may need to add to be competitive.

What’s the common thread throughout these phases of product development? It’s learning. Each phase should get you closer to developing a product that users will want to use and can use effectively.  As your investment increases at each phase of product development you need to increase your confidence in making that investment through what you have learned.