Concept, Prototype, Build in the modern world

In a recent post , I was asked if I have any thoughts on how to avoid coding new features that do not resonate with your customers. Today, I am going to share my thoughts on how to make that happen. To be clear, I do not think that what I am about to reveal here is groundbreaking or innovative. It is essentially MVP and rapid cycle development put in a differently light. While I do not think that this is new, I am very surprised at how few product management and development teams take advantage of it.

The beauty of technology is that it allows us to continually innovate and find more efficient ways to operate. In today's world, with tools such as Figma and others, we can rapidly create high fidelity prototypes that we can take to market and gain feedback on, without heavy lifting development effort done first. This innovation allows us to gain market feedback much more rapidly than traditional development cycles. It essentially involves three key steps: Concept, Prototype, Build.

Concept

This is highly traditional where the Product Management team works with the customers to define the big business problems that we should solve in the market. For an explanation of how we manage this, check out my recent post on Customer Centricity vs. Market Centricity . When you have your problem defined, you work with your engineering team to come up with a concept of a solution to your problem. The key here is that you focus on the big, unsolvable issues and less on the direct customer feedback that you get from your customer base.

Prototype

This is where the big innovation comes in. With tools we can use to design our software today, we can quickly and easily create a prototype design that allows us to visual the solution to the market. From here, we can show this to customers and gain feedback and refine the solution to what the market really wants. And we have been able to do so without any engineering effort being expelled. It is simply your design team and Product Management working together for a high fidelity mock up of the solution.

This accomplishes two key things. First, you are able to break structural fixedness of the group providing feedback with providing them something to comment on. Since many of us are visual in nature, this helps the individual providing feedback create a vision of how they might use your solution and help you refine it before you build. Second, it creates a conversation with your customer/prospect providing the solution. Whether you are "giving them something to hate" or Love, the frame of the problem allows them to provide solid feedback before you head into the next critical stage.

Build

Developer time is expensive, even if you are offshoring your engineering efforts. So you want them focused on things that will provide an impact and minimize rounds of solutions before you get to this stage. Taking the feedback from the prototype stage and applying it to the requirements and visualization in the build stage limits the point of "missing the mark" when building your solution.

Example of how to deploy

So, how do you put this into your product development lifecycle? Imagine that you are using a Agile development methodology on a Monthly release cycle. Then it might look something like this:

Month 1: Product is grooming the backlog for problems to solve. They have a key concept and begin to define a solution to the largest problems we can solve. This is your first set of requirements. You then work with your UX team to create the prototype.

Month 2: Once the prototype is ready, you demo it to the audience and gather feedback. You can test different concepts here, use the visualization to gain market feedback. They key here is that you start by defining the problem that you are seeking to solve to the client and ensure that they understand what you are going for. From there, they will provide solid feedback on how they envision solving the issue or provide examples of how they do that today.

Month 3: The requirements are refined, the build begins and you will likely have a usable product in market at your release.

Now, what should be going on is that you have product effort in all three stages every month. As the Product Manger, you are essentially working in on a concept, demonstrating a prototype and managing the release effort all at the same time. This should feed your Attention Deficit Disorder nicely and help you get great product out the door in a rapid cycle at a much lower cost.

Feel free to reach out and set up some time with me if you would like to learn how to deploy this in your efforts.