This post is the first in a series on Product Thinking:
Properly applied, agile and related approaches such as DevOps and CI/CD allow teams to build software faster. Product thinking is what allows us to deliver useful software. Our Managing Director Daniel Jones (known as Deejay) and I have had several chats around the potential benefits of leveraging a product thinking mindset in the work we do. This is the first in a series of blog posts in which we share some of those thoughts.
What is product thinking?
We’ll use the term product thinking here to reflect that there are design and organisational elements to delivering products beyond that which might be considered purely product management.
Product thinking is a set of processes used to identify, understand and prioritise problems faced by a known set of customers, and then systematically build and validate solutions that are expected to have an ongoing lifespan.
Product thinking is in contrast to project execution. When discussing a project one assumes that there will one day be a ‘finished’ state. This project’s success is determined by meeting a fixed set of requirements by a given date and within a given budget (the ‘iron triangle’). Product thinking, on the other hand, is a mindset that allows one to create continuous desired and meaningful value by allowing for a product to evolve based on real and demonstrable needs that can be evidenced. It is a pointless waste to invest your resources building the wrong things on time.
A real conversation with banking IT executives
Deejay: How do you know when a project has been successful?
Executives: If it is delivered on-time and on-budget.
Deejay: How do you know if it delivered the right thing?
Executives look confused, as if I’ve asked a silly question.
Executives: Well, there was a requirements document, so we know it delivered the right thing because those requirements will have been met.
Deejay: How do you know the requirements were right? How do you tell, after the project was delivered, if the world changed in the way that you wanted?
Executives: Oh… We’ve never thought of that.
Features of product thinking
There are four core themes of product thinking that we’ll explain in more detail:
- Problem validation
- Ruthless prioritisation
- Well-defined and measurable success
- Customer empathy
It is important to understand that product thinking is not a phase or step that happens at a single point in a system, or level of an organisation, but instead a mindset. Mindsets do not live in one place, they are leveraged across an entire ecosystem. They speak to a way of thinking or set of approaches that can inform how we go about achieving a goal. These principles, therefore, do not apply at one level - rather, they are like a stick of rock in that they run vertically throughout an organisation, applying at scales from the individual user story to corporate strategy.
Problem validation
Focus on the problem before the solution
When a doctor diagnoses a patient, they spend a good amount of time triaging to ensure that they very confidently understand what may be causing the patient their pain. The doctor will run diagnostic tests as well as collect anecdotal evidence from the patient themselves that provide quantitative and qualitative data points. Only after the doctor fully understands and records concrete evidence of their patient’s problem will they determine the diagnosis and propose a possible treatment plan (or solution).
Implementing a product mindset works similarly in that you first focus on a problem, then ensure you fully understand and can justify your reasoning before moving forward with a potential solution.
Some examples in practice include:
- Proper scoping and discovery activities that define the current state before starting a programme of work
- Artefacts that clearly illustrate why an activity needs to be done
Ruthless prioritisation
Address the riskiest assumptions first
Continuing the same metaphor, a patient may go see a doctor with several issues. The doctor will assess the patient and then do their best to determine which single issue is posing the greatest risk to their patient’s welfare. This will most likely be the first concern that they will focus on and address.
Fixing the most important thing first means the doctor still has a patient to continue working with - there’s little point addressing someone’s athlete’s foot if they’re bleeding to death.
One should make the biggest pains clear and prioritise what will be the most valuable and impactful to the customer, and do so ruthlessly. By doing this the overall risk is smaller and effort won’t be wasted treating the wrong things.
Some examples in practice include:
- Prioritisation of programmes at the strategic level
- An understanding of a given solution’s cost of delay
- Ordered backlogs as opposed to jumbled messes where everything is top priority
Well-defined & measurable success
When you know what success looks like, you know when you’re done and what to do next
Product thinking provides a way to test and measure outcomes to ensure you return significant results, regardless of whether they are positive or negative.
Significance is the ultimate goal of a test. The worst situation that a doctor can be in is one where they run a test and the results are inconclusive. If the conditions of the test are not clear, variances have not been accounted for before starting, or the doctor is not sure what they are even testing for, any results that are returned are fairly useless to their ability to diagnose and treat their patient.
Additionally, it’s important to reiterate that the success of the test is determined by ensuring that, regardless of the result, there is enough information to make informed decisions about what to do next.
Some examples in practice include:
- Features/programmes containing a specific hypothesis about what measurable impact they will have
- Mechanisms to measure and track metrics that will determine the success of hypotheses and determine if the outcome is valuable to the customer
Customer empathy
Shared ownership of empathy for users in the team means increased accountability and lighter individual loads.
Before your customer is a product, or a persona, or a user, or even a customer; they are a person. We in business often forget this, focusing more on codifying and extrapolating people to fit our business needs. The real value in product thinking comes from a readdressing of the balance of peoples’ needs and business needs by listening much more closely to the person speaking to us. Their lives, their situations, their wants, needs, desires, and fears.
Product thinking aids in building this empathy for users, and an emphasis should be placed on the importance of delivering value that is owned and understood by the entire team. This provides a sense of purpose and also an insight for the team into how their efforts directly impact the things they are producing; making for more commercially intelligent teams. The team should then feel more empowered to ask why they’re building what they are, and to invest in, and take ownership of, outcomes as opposed to outputs.
Increased empathy in teams can also work to increase the ability to show vulnerability earlier and more often. This means teams are able to ask the questions necessary to produce solid solutions. They can call out shortcomings so they can be addressed. Teams with emotionally robust environments are truly able to fail faster and do so without fear of blame or punishment.
The most important thing is solving customer problems together and effectively adjusting their shared process, as opposed to using hero moves that can lead to weak spots in how they deliver value.
Some examples in practice include:
- Identifying and recording customer personas
- Cross-discipline pairing, early and often, to ensure that customer needs are visible to practitioners
- Increased feedback loops that run both horizontally and vertically within an organisation
Why is product thinking important?
Product thinking is important as the next frontier in building useful software, and in creating resilient organisations.
Agile can help you go as fast as you like, but if you’re building the wrong thing, you’re screwed anyway - no one will use what you build and the chances are that a great deal of waste will be created in the process.
If Agile is the vehicle you are travelling in, then product thinking is the navigation ensuring that you’re tracking in the right direction on your journey.
Product thinking captures, and holds teams accountable to justifying, the intent of their actions. In a space where work is justified and actions are intentional, less waste will occur.
Agile software delivery is a largely stagnant field - for years at EngineerBetter we’ve been helping people deliver software more quickly. Cloud Native practices allow us to create resilient and highly-available systems on global scales. Both are generally well-understood even if adoption is poor and lip-service is prevalent.
We’ve observed that many in our industry spend so much time focusing on the tech and the solution, that they haven’t done enough to determine if the solution solves the problem for their users in the first place.
It’s often forgotten that at the heart of technological advances we’re ultimately trying to solve problems for people and add more value to their lives! When thinking about what success looks like, it’s important that we’re measuring the right things (or even taking measurements in the first place).
Neither Agile nor Cloud Native alone are enough to build software that is useful and that changes the world in the intended fashion. In short, they don’t help us build the right thing.
Who should apply product thinking?
Anyone that is building a product or offers a service can benefit from product thinking and associated tools and practices. The greater the uncertainty in the problem, solution, or delivery method, the greater the benefits of applying product thinking.
Product thinking applies to anything that offers self-service with an ongoing lifespan. Digital experiences, apps, platforms, as well as abstract systems such as communication loops, services and information flows could all leverage these techniques.
It is only by:
- explicitly identifying those suffering a problem
- understanding that issue
- hypothesising what might help
- building that proposed solution
- checking the solution had the intended effect
…that we deliver useful software.
Previous article
