The most successful product development teams not only have great experience and capabilities but a 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 needs 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 straightforward plain language questions, that's 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'll mean the whole team will be engaged earlier in the process, allowing them to open up other methods of assumption validation.
In this article, I'll focus specifically on:
Starting product development 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.
NB: There's an example at the end of this article.
1. What's the customer's problem?
The customer problem that the team is attempting to solve.
Solutions are only as good as the understanding of the customer problem that's being solved. This needs to be a real human problem or challenge that the team is solving by creating value for the end customer.
It's 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 the 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 discovered 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's the team’s goal?
What we intend to do to see if customer behavior changes.
This condition does not prescribe a solution, but rather an intended goal that frames how the team might solve the customer's problem.
With the team collaborating and discussing what they are trying to achieve, what they want to learn, and what might get them there they'll 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's 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 problem-solving matter?
Define 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 realize 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 favor of plain language, the business benefit shouldn't 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 behavior change 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) come in the form of behavior 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'll allow them to iterate on the solution further, learning as they go.
Success doesn't come in the form of product metric changes or business outcomes. It's no bad thing if these change, but it doesn't 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 personas. At the most basic level, there are always new customers and returning customers. There might also be loyalty programs, various channels to acquire and engage, advocacy programs, customers that buy certain products, or services over others - the list goes on.
It’s important to be specific with the type of customer the team is focused on. It'll 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 product development
With these starting questions answered, it'll 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 learned 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 to know 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.
Is the team confident enough that what they’ve designed and built could solve the problem?
2. Does the solution apply to our product principles?
Product principles are used as a framework to guide product decisions and to help evaluate the ongoing work being done.
They're 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's 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?
- 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're encouraged to purchase more items more often.
- Why does it matter to the business?
Some customers are unable to pay in full and therefore abandon 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 program customers who make large purchases only every six months on average.