The most successful product development teams not only have great experience and capabilities, but the deep understanding of what customer problems they are trying to solve and why that's important to the business.
Teams should be able to work with a level of autonomy that allows them to solve customer problems in the best way possible. This lightweight structure allows them to clearly state those problems, how they are intending to solve them and when to stop and release value to customers.
By defining a set of conditions, in the form of straight forward plain language questions, that are consistent across the product development organization they are able to ensure that early stage product conversations are geared towards a process of learning. Moreover, it will mean that the whole team will be engaged earlier in the process, allowing them to open up other methods of assumption validation.
Starting the right way
At the beginning of any new initiative answering these questions will support a product development team’s understanding of their purpose; the problems they are solving, goals they are trying to achieve, value to the customer and benefit to the business.
It is important that Product Managers, Product Designers and Engineering Leads are aligned on the problem they are attempting to solve and know why it is important. Answering these questions is a team activity and each discipline will have a specific viewpoint that will shape how the initiative is taken forward through the whole product development lifecycle.
Note: There is an example at the end of this article.
1. What is the customer problem?
The customer problem that the team is attempting to solve.
Solutions are only as good as the understanding of the customer problem that is being solved. This needs to be a real human problem or challenge that the team is solving for by creating value for the end customer. It is vital to get this right as the solution can be entirely different based on the vast and deep understanding of the problem.
The answer to this first question must be agnostic of solution, meaning that there should be no mention of a solution within the problem statement. To do so would lead the team down a predetermined path, therefore restricting both the team’s creativity and the end solution regardless of what the team discover along the way.
A customer problem should not be so specific as to point to any usability issues or pain points, it is also not a technical issue, business problem or an afterthought that’s been reverse engineered from a solution.
2. What is the team’s goal?
What we intend to do to see if customer behaviour changes.
This condition does not prescribe a solution, but rather an intended goal that frames how the team might solve the customer problem. With the team together discussing what they are trying to achieve, what they want to learn and what might get them there they will have a greater opportunity to solve the problem.
The team’s goal may change over time the more they learn about the customer problem. As a starting point it is good to consider the goal in one or two weekly increments. This allows the team to be flexible in what they are trying to learn depending on the complexity of the problem they are faced with.
3. Why does solving the problem matter?
Defining early why it matters to both customers and the business.
From a customer perspective solving this problem must add value to them. It must allow them to achieve something they couldn’t prior to the solution, introduce something completely new they didn’t realise was possible or simply improve something they were already doing.
The second part of this question is reliant on achieving the first, the business benefit can only be answered when we know what customer value is added by solving the problem.
For product development there are really only four reasons why a business cares about solving customers problems; increasing revenue, reducing costs, acquiring new customers and engaging returning customers. Anything that achieves these for the business is beneficial.
In favour of plain language the business benefit should not include any calculations or forecasted metrics. The question should be answered as if a colleague had asked why the work was important.
4. What does success look like?
The customer behaviour change that determines success.
When the team releases a potential solution to a specific group of customers the indicators that will show success (i.e. the problem has been solved) comes in the form of behaviour changes those customers are showing.
Even if customers react in a different way to the one intended the team will learn more about the customer and what they are trying to achieve. This will allow them to iterate on the solution further, learning as they go.
Success does not come in the form of product metric changes or business outcomes. It is no bad thing if these change, but it does not give the team the knowledge of why it happened, nor does it allow them to continue learning or know how to iterate further.
5. Who is it for?
The specific type of customer which we’re focussing on.
Most businesses have a variety of different customer types. At the most basic level there is always new customers and returning customers. There might also be loyalty programmes, various channels to acquire and engage, customers that buy certain products or services over others and the list goes on.
It’s important to be specific with the type of customer the team are focused on. It will allow for greater focus during design iteration, testing and understanding how, when and why it might be worth rolling it out to a larger customer base.
Even though the customer problem may be the same, the solution may differ greatly depending on the customer type. For example: returning logged in mobile customers of high tier loyalty access versus new customers coming to products directly from search engine advertising.
Knowing when to stop
With these starting questions answered it will allow the product team to start working on an initiative only when there is a deeper understanding of why it’s important.
Additionally having simple questions that book-end the work will support their understanding of when to stop design and development work, release iteratively and articulate what they’ve learnt during the design process.
Each question requires a positive answer to move forward to release.
1. Could this solution solve the customer problem?
It can often be challenging knowing when to stop working on a solution. Usability and A/B testing can be used to de-risk and build confidence but ultimately the team will learn the most when the solution is live and being used. Are the team confident enough that what they’ve designed and built could solve the problem?
2. Does the solution apply our product principles?
Product principles are used as a framework to guide product decisions and to help evaluate the ongoing work being done. They are defined as a unified, shared language of ‘what good looks like’ to ensure that teams are delivering quality experiences. Does the proposed solution apply these principles effectively?
3. Does the solution fit with the rest of the product and experience?
At larger scale organizations with multiple products, or teams working on the same product, it is vital that the new solution fits within the existing ecosystem. It might solve the immediate customer problem but can the team confirm that it doesn’t damage the customer’s experience elsewhere?
Example
- What is the customer problem?
Customers sometimes struggle to afford large purchases. - What is the intended goal?
Provide customers more flexibility when purchasing so that they are encouraged to purchase more items more often. - Why does it matter to the business?
Some customers are unable to pay in full and therefore abandoning their cart at the final moment of purchase which impacts revenue. - What does success look like?
Customers are able to pay in a more flexible way which results in an increase in conversion while returns remain stable or decrease. - Who is this for?
Returning loyalty programme customers who make large purchases only every six months on average.
