How To Identify the Right Product To Build

Problem

Today a lot of startups are focusing on how to build a product right, but before that, you need to figure out the right product to build. You normally have the CEO or some executive picking a product based on their knowledge or opinion. They are often seasoned so they know the business and market, so they also think they know the right product for their client. This sometimes leads to them managing the team directly or managing the team through the demands of the product. In many cases, you have the old waterfall organization structure and you have the PO managing the delivery, so the discovery comes down to business cases made by analysts from internal data.

To me, there are two main problems with this. A good methodology is needed to validate or invalidate certain assumptions. Sometimes bosses and organizations get assumptions right, but some assumptions are always going to be proven wrong. When all your decisions make a big impact, you need to reduce risk by making sure there’s data behind assumptions, and if you fail, you need to fail fast. You test your riskiest assumptions at the beginning, so you know at the early stage whether the knowledgeable person’s assumptions were right or wrong. This will reduce the cost and resources you spend.

The second problem is cultural. It is more difficult here because these are people and organizations who are not used to talking to their customers. They do not understand the importance of building a product that solves a real problem. They look at the market trends, they get information from investors, or they read information without understanding what it means. Some people just work on intuitions. Again, this may work early on, but at some point, it will lead to building products that don’t totally make sense. Once you’re proven right once about your intuition, you think your intuition is always right. You need to be customer-driven. This will make the company more flexible and will reduce the risk of failure.

In the initial phase when the startup begins, you need to build and learn, measuring things from day one. However, organizations often focus on the building phase, and they lose track of the client. Organizations need a holistic approach to setting up a proper process of getting the right product to build. This involves concentrating the same amount of time you spend on delivery towards the upper parts of the product life cycle.

Actions Taken

The product managers, together with the designers and the engineers, need to go out and talk with the customers. What we implemented across the companies I’ve been working on is a very collaborative approach made of four different phases - problem identification, solution fit, solution delivery, and the analysis of the results.

In each stage, the product manager, product designer, engineering manager of a typical squad (if you want to recall the Spotify model) are involved as stakeholders and engage cross-functional resources - such as product marketing - as needed. At the start of a product, these teams should try their best to identify the risks involved from perspectives such as viability, legal, medical, or even ethical. Try and identify these risks early - there is no coding yet.

When you start tackling a project, start digging into why this project exists. Start doing the discovery phase even though they are not asking you to do it. They are probably asking you to implement a full solution, but you can fragment the project into smaller pieces to start exploring. This lean process in which every member of the team is involved is something you can’t implement from day one because you don’t have the trust of the stakeholders yet. Most organizations are done on a project basis and they don’t have a product mentality. You need to win over their trust and show them that what you’re doing is actually impactful.

There are several techniques for identifying value. You can provide a service that your clients would be hiring for and “faking it until you make it” to see if there’s the value behind it. Anything you would be building beforehand would be useless, it would be the perfect solution nobody will use. This first phase will involve the engineer so they get the “why” behind the things they will build. It needs to be focused on the problem you are solving. It can go down to the identification of the solution and then only then go to the delivery phase.

Now, you can tackle this fit evaluation by making a very small MVP if pushed towards a product, use existing solutions, or even white-label a solution from someone else. You want to test viability and usability from an early stage. If you figure out that this product is the right one for your clients and see that it’s easy to engage the members of the team, it is easy to engage stakeholders and clients as well.

At some point, you need to make a go-to-market strategy to focus on delivery. If you didn’t find something that was valuable for the customer, you will need to invest a lot of money in marketing, sales, and support, since people will not understand why they need your product. You would be creating a need from scratch which doesn’t solve any real problem. Remember, a client is buying a product because they are solving a problem through a bunch of tools or manually. You are providing digitization of tools to run that job for them. If you find that problem out at an early stage, you will have a machine that will discover new problems while solving it. The results of that are going to feed into the new discovery that is going to then be the trigger for new initiatives. The whole team will be on board with that if that really get the idea behind what they’re doing. You can align people by setting objectives like OKRs, but a lean approach and a collaborative approach that involves everyone in product development is the best way to gain trust and to deliver the best value.

To analyze the results, we make one-page documents with lots of information such as the problem, intent, allocated, and resources. You can use these to figure out if the assumptions have been validated after testing, whether you need more resources or fewer resources depending on results, or evaluate if you are looking at the right problem or the wrong problems. Having a structured knowledge base where you store information is key, but these documents tracking intents are even more important. You need to align people towards intent and clarify this intent as much as possible.

Lessons learned

In summary, in order for this all to be effective, we need to work under specific circumstances:

1. Failure needs to be accepted and autonomy needs to be given to the teams to operate under the best conditions.
2. In such volatile and fast-paced changing environments, collaboration is key to guaranteeing that the whole team is motivated and onboard.
3. Continuous discovery and continuous delivery is the only way to guarantee business impact and reduce the risks of failures.

To ensure this, I have sprints of two weeks in parallel where we do this activity where we gather the whole team, we discuss the problem, discuss solutions, look at the solution designed by the week before, and then look at the results of a product two weeks in advance. You are going to design something that is being built the next week and analyzing something built the previous week. This helps keep people focused on the reasoning for products rather than just execution.

In every phase, you need to have time-boxed activities. You can’t have a team doing discovery forever or always working to find the most scalable solution. Timeframe, in the old scrum methodology, are the sprints the development team used to have a sense of ending. We reuse that concept in our lean product development process. The team needs to understand every phase of this process and be given time to figure out the best design and working solution within that timeframe. They should always bring this into account and then iterate.

To drive the product forward every meeting, you need to have methodology so you know where you want to go. These objectives will help define what the path is. Along the way, once you are analyzing an opportunity based on some assumptions, you need to have a clear document detailing all the information that was been gathered, through the assumptions and data.