The way I build products.
“Systems that do not engage with failure struggle to learn.” Matthew Syed
There are no secret recipes to build good products, I don’t trust those who translate their success into easy digestible bullet points. Good products are incredibly difficult to build and through failure after failure I’m learning and shaping my process. Nowadays my product practice is deeply interconnected with the human-centred design process: focus on understanding the context where people operate and their behavioural drivers.
My product journey is mapped in a double diamond model: a tool to set up, frame, organise, structure and manage products. I go broad before going deep because creativity happens when I start to explore tons of ideas, then empirical evidence helps narrow down the best ideas and prototypes give a more clear conclusion. I aim to build products as a system of independent small features, this enables us to build and test in isolation.
In case, you are familiar with the British Design Council’s Double Diamond, IDEO’s human-centred design ideology or @d.school’s Design Thinking process you might find my approaches a simplification of them, with some sort of pragmatism due to the fact that I operate internally as part of the scrum process.
Step 1, focus on Framing the Problem.
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Albert Einstein
A product succeeds because it solves a problem for people. This sounds very basic, but it is the single most important thing to understand about building good products: understanding what problem I want to solve, and for whom. Then I ask myself is this a problem worth solving? The problem statement must be crystal clear before I start thinking about any solutions.
Recently I’ve worked mainly for startups with a narrowly defined audience, where generally the research phase takes just a few days to be defined: mass-market products may require extensive research but with niche targets research can be less extensive.
Step 2, focus on Building the Solution.
Good execution is about getting to just enough conclusions in the shortest amount of time possible. Bad execution is when something takes a long time to be implemented and fails and you don’t know why it failed.
Mistakes are the very best way to learn and when I’m successful I’m able to answer:
“What lessons did I take away or what could I have done better?”
Measuring success is critical for learning and the team rallies around it.
I define the success metrics before launching. For each success result, I work backwards to get a measurable metric and I keep asking myself “why?”, to fully understand what moves the numbers.
Sharing the success metrics with stakeholders is fundamental and when I find myself constantly getting into debates about product direction, the root cause is probably a disagreement in the way we are measuring success.
Remember it’s all about the team.
“Only one is a wanderer; two together are always going somewhere.” Alfred Hitchcock, Vertigo.
I found out that learning-oriented and problem-focused teams have more successful outcomes than teams that jump into solutions and are mistakes adverse. Knowing that a problem is worth solving is a strong motivator and sharing mistakes is the way to adapt in the complex world of products. When I write the product brief the goal is to experience the problem in a most realistic way.
“What can I do that will most help my team be successful?”
Good communication is the key for a healthy team. I make sure every member of the team feels safe to express their viewpoints, even if those views are contrarian: diversity of opinions is how I get to the best products.
