What is a product mindset?
People can read many different things into what ‘product mindset’ means. So before I make any recommendations to organisations that wish to adopt one, it’s important to be on the same page about exactly what it is we are talking about and be clear about my own biases.
For me, having a product mindset and building strong product culture includes the following things:
- Being ruthlessly user or customer-centric with decision making guided by insights including user research and behavioural data
- Empowering cross-functional teams to solve user/customer problems (in ways that make sense for the business) and measuring success on impact rather than telling them to build features and measuring their success on output
- Taking an agile and iterative approach that enables you to rapidly learn and improve by delivering stuff
- Adopting a guiding vision for the impact you want to have in the world and a framework to coherently deliver it by aligning multiple teams that have a good degree of autonomy over owning particular aspects of it
It’s about treating what you’re creating as ‘a product’. This means understanding the answers to the following, often referred to as product discovery:
- What do your users want? What are they trying to achieve? Does your product help them do this?
- Can they use the product? Are they using it as expected?
- Is it technically feasible for us to deliver (and maintain) it?
- Is there a viable business model to support it?
And when you’re delivering your ‘product’, is it reliable, robust, safe and secure? Plus, can you scale the delivery to all of the people that want it and is it sustainable to do so?
Note, that none of this is necessarily specific to digital. I believe that this mindset can have a huge beneficial impact on businesses that are not digital product companies and/or where building technology is a small or non-existent part of its activities.
However, it’s particularly important for companies that are building digital products.
Technology is often used to solve problems in new and different ways. Delivering novel solutions is fraught with uncertainty and unknowns, plus technology is often complex, requiring people with different skill sets and perspectives on the world to work together.
To genuinely use technology to solve problems, the organisation needs to treat it as a core competency and empower those that understand it to devise solutions, rather than simply treating it as an overhead and delivery function.
In my experience, many organisations struggle to do this because it requires a leap of faith and mindset shift, particularly at a leadership and organisational level. Often, those further down the organisation involved in hands on delivery and closer to the customer/user are trying to adopt many of the practices mentioned above but struggle to do so effectively because of how the company is organised, managed and led. So you need to consciously and deliberately create the environment for this to happen.
The default position is often management deciding what needs to be delivered and handing over to teams to deliver. Sometimes this also means that one team designs it and hands it over to another team to deliver it.
This fundamentally means that teams have less understanding of what problems they are solving and so do not solve it in the best possible way - teams are often closer to the customers and understand the technical constraints better.
Giving them solutions means that they feel less ownership over it - they may even clearly see why it won’t work - and so typically they deliver less than an empowered team tasked with problems to solve that they understand and care about.
Ultimately, it also means you’re measuring the output, rather than the impact. And impact is what really matters to customers and the success of the business.
In order to make the leap, it’s about letting go of the things that appear to provide comfort to those of us in a leadership position. For example: roadmaps with features and precise dates. An assumption about the impact that a particular feature will have before there is evidence to support it. Or that simply adding more people will enable you to deliver more. These things rarely come to pass.
Instead, the things that should provide comfort are the following:
- A well articulated, inspiring vision of the change that you want to make in the world that motivates your teams to make it a reality
- A clear product strategy as to how you plan to go about this based on insights and data
- The people, culture and infrastructure to gather insights: collecting and reporting data and regularly doing user research
- Small, cross-functional empowered teams who are clear about the problems to solve, have the mix of skills required to solve them and who are measured on impact not output
- A stable organisational ‘topology’ (made up of many ‘bands’ rather than a single ‘orchestra’) that enables a team to have long term ownership over a particular domain, develop a deep understanding of their problem space and the technology they are working with to solve it. Plus, be able to build stable relationships with their teammates
- An agreed set of product metrics that measure what matters and guides decisions
- Teams that engage in product discovery as well as product delivery to validate solutions quickly and minimise investment in things that don’t work
- The frameworks and organisation that creates clear alignment with the company strategy and a clear planning cadence
- Lots of coaching and support to ensure that the people are solving those problems are doing so in the best possible way, have all of the required context and are aligned with the strategy and other teams
- A culture of learning and continuous improvement, with the space for regular reflection, and the appetite to adopt new approaches
- Good people with the right mindset to create, embrace and thrive in the culture outlined above
All of this is hard to achieve but not as idealistic as it might sound. The crucial bit is the desire and appetite to adopt the right mindset.