A proper product management and design process should, as a foundation, include the people who are the target audience for the product in question in order to understand how close or how far the proposals are from people’s needs and cognitive flows.
This is not solved by doing “usability testing”. A lot of companies and teams claim that they’re being customer-centric by doing usability testing, but it is not enough — it’s definitely better than nothing, but involving customers in advanced stages of product development is not the best way to work responsibly. Delegating customer-centricity to usability testing implies that the team already has a more or less workable version of the product or feature to actually test. And, to have gotten to this point, work effort must have already been spent on boiling through a bunch of assumptions.
Those, if are not hypothesis coming from research about the product’s audience, might be wrong and, in this case, a considerable volume of resources will have been wasted. Most importantly, time to market is compromised. A product idea or feature decision should be rooted in evidence of its concrete meaning to the audience in question. If this is verified too late in the game, the product will suffer with launch delays, useless features and customer disconnection.
A successful product should do the job of bridging the gap between a person’s current self and their projected image of their future self. The product manager and the designer’s role will float around ensuring that, most importantly, the destination is reached and that the journey is smooth and delightful.
Alice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don’t much care where.
The Cheshire Cat: Then it doesn’t much matter which way you go.
Alice: …So long as I get somewhere.
The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough.
(Lewis Carrol, Alice in Wonderland)
The Double Diamond, proposed by the British Design Council, is a nice way to visualise how this process goes about, and can be adapted to wrap the whole process of product development (not only the design part):
DISCOVER — Frame the problem and uncover needs
During the discovery phase, the majority of the time should be invested in investigating problems, without yet an eye to solutions. Budgeting for and exercising exploration is key — and, I repeat, this is BEFORE defining solutions.
This phase should be the one deeply rooted in user research — and this is the most important moment of all the process. The energy you invest in defining problems and outcomes will be well paid later in the game when crafting solutions and moving to more visually tangible deliverables.
It’s not uncommon for this phase to be highly overlooked by companies or badly managed by those involved. This is hard work to do, emotionally intense, requires training and study of the tools and research methodologies, needs to be adequately structured and, for those not schooled in proper product management, might sound and feel wishy-washy. But, if you want your product to stick to people, why not start with people?
Jobs to be done is my favourite framework to structure this step. In this phase, it’s based on:
- Defining the core functional job that the product is catering to;
- Doing JTBD interviews and observations with potential customers affected by the problem you’re trying to solve in order to: a) understand to which jobs they hire this or similar products to do for them; b) line-up and explore the relevant outcomes for the customers; c) figure out alternative ways in which they are currently solving the problem.
- Preparing the 8-step job map in order to visualise the main jobs involved in each decision;
- Define the outcome statements for the jobs, along with their performance metrics.
JTBD interviews are quite peculiar to handle. The main objective is to understand the users’ push and pull factors in each decision, so their success depends on the interviewer’ ability to conduct the journey and feed the interviewee enough clue to help him/her remember the details without asking leading questions. A lot of “why” and “tell me more” and “can you explain me more” are required. Curiosity and empathy are fundamentals to the process — the main pitfall is falling into confirmation bias.
This requires training and skills on how to interview — leading questions, even if they soothe your soul because they seem to validate your own ideas, won’t bring you any real value in the end. We do research to reduce confirmation bias in our product decisions — be open to hear and to be humble when you’re wrong. Nailing this is key — badly conducted conversations will lead to badly formulated problems. Check part 1 and part 2 of a JTBD interview to inspire your script.
Other useful tools in this step are:
- Going through available user feedback: Every company has already some body of knowledge of customer feedback. It’s probably being collected, but perhaps not being paid the right tone of attention to 🙂 Remember that this step is about framing the problem: resist the temptation of jumping into the implementation of solutions suggested by your customers. Some people do not necessarily express themselves in a problem-focused language — they use the solutions language to exemplify what they mean because problems are archetypal abstractions of issues they face in their real lives. It’s the product manager and the designer’s job to read through the language and to uncover the problems. If you mean to use customer feedback as product prescription, maybe it’s worth to check the example of how Homer Simpson-as-a-customer car might look like.
- Service safari: Go out in the field and just observe how people, when unguided, are currently solving their problems in the area that your product intends to affect. Pay special attention to the workarounds and creative mishmashes they find in the wild to deal with their issues. Remember that they’re only attached to a solution as long as it’s effective towards the objective they want to achieve.
- Shadowing: Shadow people during the execution of the required tasks to achieve their required outcome in order to feel the pain points.
- Contextual interviews: Conduction of customer interviews while inserted in the environment in which the product or service will be used — can be seen as another type of shadowing.
Don’t rush through this step. It’s natural and expected to feel scared during this process, since our competitive work environments and often badly designed employee incentive systems wire us to want to control the outcome of things and to be passionate about solutions and deliverables (as they’re rewarded as the only “real work”). Research is real work, and requires love to be wheeled in motion (cheesy, I know).
DEFINE — Streamline what will be done and when
With the foundation coming from the structured problems and desired outcomes perceived during the discover phase, it’s important to define a product hypothesis and to prioritise the handling of the customer outcomes. This can be done by understanding which of those jobs are being underserved, well-served and over-served. This prioritisation strategy is specific to local realities and platforms.
Some tools that advance this step of the diamond:
- User story mapping: An alternative version of the outcome statements, is also used to organise and prioritise development, considering the pre-service, during-service and post-service moments.
- Ideation processes: The definition of solutions can tap into the company’s body of knowledge by involving people with multiple perspectives.
- Prototypes and wireframes: Allow visualisation of solutions and structures towards the finalised UI design.
- Usability testing: Bring your target audience to the stage to perceive execution problems, collect feedback and iterate over proposed solutions. Use this moment to understand what and how to release sooner in order to validate concepts and get to market quicker.
- Card sorting: Drill on information hierarchy by understanding how users perceive and mentally organise topics in their interaction with solutions. Helps avoiding confirmation bias when designing the solution’s journey.
- Design patterns and visual style guide: As the design sweeps into development, define the required basis of healthy design evolution, foster consistency and save time. More about this topic here.
- 6-pages: Used to communicate strategy and solutions by using storytelling as a means of influence and of obtaining buy-in from relevant stakeholders.
Define the measurements of success and enable the actual measurement to happen by creating a tracking concept. If you can’t measure, how will you understand product performance? Remember that the outcome statements already point out to the definitions of success — just make sure that you can collect this information and interpret it in a timely fashion.
DEVELOP — Use resources responsibly
Once the delivery of outcomes is prioritised and defined, it’s time to make it concrete by using resources in a smart way and ensuring that good quality experiences are being worked on by the team. Prototypes, user research and usability testing all come back on this step to refine and iterate.
On the software development side, extensive references can be found about agile and its most known frameworks, Kanban and Scrum. I choose to work in agile-powered environments because, when well executed, it allows me to ship faster and constantly for shorter feedback cycles.
I used to be quite by-the-book with regard to processes in this step, but the more time passes, the more I want to eliminate work done for the sake of doing work. I now prefer to pick what makes more sense for me and my team: if we need something to happen, we discuss the ways to make it happen without being too attached or radical. In this regard, I value “not joining the cult” and trying to be a bit more organic in those decisions. Usually there are other industry cases in which we can inspire ourselves and try solutions for our problems without reinventing the wheel or being excessively prescriptive.
DELIVER — Concretise your impact
Deliver, measure, iterate — rinse and repeat. Once again, don’t deliver for the sake of ticking boxes — don’t let the impact you’ve created die in the mud pit. This is a cyclic process, even when you’re handling different problems and designing solutions for those other problems.
And, most importantly, don’t refrain from collecting feedback from your target audience — do it and use it smartly. The same principle of not jumping to solutions when hearing feedback is required again — people don’t want faster horses, they want less horse shit!
A couple of tools to help:
- User interviews and surveys: Can be used as means to collect feedback and dive into execution details and fails.
- Usability testing: Once a solution is in the wild, unforeseen problems and opportunities will surface… Rise and shine to the new windows that then open for the product team to pry onto!
- A/B testing: Allows quick reaction, optimisation and experimentation. A product strategy shouldn’t consist on a sequence of A/B tests — those have the specific objective of facilitating flows and steps and to smoothen journeys towards outcome. Read more about conservation of intent.
When exposed like this, proper product development might seem like a lot of work — and it is. It is definitely easier to just follow what someone tells you to do or execute and implement ideas coming from the head of a CEO and with no real-world foundation. Then again, failures shouldn’t come as surprises if product is managed this way. As a qualified product manager, you and the team you’re part of decide where to compromise and why — and hold the rationale that supports your process and decisions.
If you’re a product manager or a designer in the beginning of your career, you have lots of company — we’ve all been there, we’ve all failed, we’ve all tried again and learned out of our mistakes. We’ve all regretted choices: I’ve mostly regretted money-led choices of working in companies and environments which are not fertile to smart product development, since it only delayed my evolution into a resourceful product manager and it robbed me of precious time to improve myself and, thus, to better do my job. But those mistakes are unfortunately the only way to learn deeply under your skin and to sharpen your skills. The more your do that, the more invested you become in targeting the outcome, the more efficient and proficient you become in executing and strategising product — and the more curious you end up being in life, in general.
The tools mentioned above should all be part of your toolkit as a product manager or as a designer, and you should know when to use them and which job they do for your product development journey. Don’t to do all the above all the time — part of the skill of this work is being smart about which tools to extract from your toolkit in order to better serve the desired results. Avoid doing work for the sake of doing work — do it for the outcome! The impact will astonish you.