Becoming a customer-centric product leader
Investing in a culture of research and design gives a clearer direction, accelerates you as a product leader, and has a great proven ROI.
- Product Management teams all too often focus on delivery over customer outcome. This is a cycle that leads to poor financial results.
- Companies that invest in research and design are proven to perform better.
- You as a Product Leader have a responsibility to ensure customer-centric behaviours in Product Managers and adequate investment into design and research.
- There are simple (but not always easy) improvements you can make to culture and team structure to achieve better results.
I wish I had known when I started…
It was my first month. The priorities were clear: growth and international expansion. On top of that, the CTO said we needed to rebuild our mobile app.
One year later: new markets weren’t meeting our expectations and our app was a flop with beta users.
What had gone wrong? We didn’t know about the customer to make good decisions.
Companies that understand customers perform better
Although most company leaders aim to build products that customers love, too many companies build products based on an unstable foundation of inadequate research and gut feeling leading to market flops.
Software development is expensive, complex and time consuming. Once software is created, it’s even more costly to make changes later. Research over the years has shown that companies working with immature processes have costs of reworking existing code from 4x to 100x the cost of the original development.
Therefore investment is needed into understanding the customers to build and design the right product in order to avoid making expensive mistakes.
In short:
Investment in user research decreases risk of market rejection.
‘Output over outcome’ creates a cycle of poor results
As a product leader, you are responsible for making sure your team has the skills and resources needed to create great products.
All too often companies and product managers get stuck in a mode of valuing output above all else. There’s an overall feeling that they should be delivering faster than they are — they feel like everything is delayed or running behind.
Melissa Perri in her excellent book, ‘Escaping the Build Trap’, describes this as focusing “more on shipping and developing features rather than on the actual value those things produce.”
After working with startups for the last 12 years, it’s clear trend that companies who feel they are behind in delivery end up chasing a cycle of poor releases, leading to poor business results.
In this environment, product managers aren’t given the support or time needed to understand the market and its customers. Instead, there’s an overwhelming feeling to prove the team’s ability to execute.
As product managers don’t have reliable insights and designs, they commit to ideas that haven’t been validated.
These unvalidated ideas are less likely to solve customers’ problems which results in poorer business results, reinforcing the cycle.
Be systematic — you’ve probably outgrown the CEO just ‘knowing what customers want’
When a company starts, the founders and first staff generally develop their product in quick iteration with potential customers.
Informal communication between founders, team members and personal contact with customers is enough to develop a successful product.
As a company grows staff positions become more specalized (like Product Managers) and end up further away from the people using the product.
Without systematic user research, Product Managers end up filling backlogs with items from stakeholders, upper management or general guesses for what might work for customers.
When a company outgrows informal user insights, it’s up to you to define a better, systematic approach:
There are four aspects of a systematic approach to research:
- Regular
- Written
- For a wide audience
- Using dedicated resources
How to break the cycle
- Get the customer in the minds of Product Managers — Ensure Product Managers can name the main ‘jobs to be done’ and customer pain-points. Matthew Godfrey gives a great management-level view of JTBD.
- Product Manager hires from departments like Customer Care won’t themselves help customer knowledge long term — They’ll bring a short-term boost to market knowledge in the team but won’t provide a systematic approach plus they’ll focus on learning core product skills in the first months and years on the job.
- Start small but keep it regular — PMs meeting customers once a week. Surveys once a quarter. Get help from other departments like Customer Care and Marketing.
- Create a standardized user research repository — Create templates for user interviews. Store results in one place. Konstantin Escher wrote a fantastic article on How to build a User Research repository in Notion, step by step.
As your hire, balance the team
When I was a fresh product leader, we were rebuilding our mobile apps at the same time as tripling the size of the team.
We had done a great job of hiring lots of Product Managers and Engineers. We had a whole new team of Engineers and two Product managers. We hadn’t had as much luck with product design and research.
Ambitiously, we tried to fundamentally change the UX of our apps at the same time as rewriting them. The original idea with the staff we had at the time would have been to rebuild the app to provide a technical basis for future changes. This would have been a better approach.
Unfortunately trying to pursue these two aims resulted in a worse UX, unhappy customers and a 4 month rework projects.
The causes were clear:
- Pressure to fill backlogs — By far the biggest issue. The Product Manager and Designer were under pressure to ensure that the developers didn’t run out of meaningful work.
- Unvalidated user problems — We hadn’t yet qualified and quantified problems with the user experience, instead we took our best guesses.
- Inadequate mockups, wireframes and user testing — We began development before we knew what the best solution was for users, caused by…
What’s the right balance?
Give your teams between 20–25% budget and people (source) for design and user research. 1 x designer per team and access to analysts + user research support.
How to break the cycle
- Give adequate budget — Explain the ROI and reduction of risk through research and design to budget deciders. Be open to adjust budgets from open Engineering and Product positions to balance the team.
- Decide how research and design will interact and be structured — Three models to consider are centralized, embedded and the elevator.
- Understand what it takes to hire good UX people — You’re probably already set up to hire for Product Managers and your tech team versed in hiring Engineers. You need to be attractive to UX people. Marissa Louie’s article is well worth a read on 20 laws of recruiting top designers.
Spreading everyone too thin…
Working in product management for the last 12 years with start ups, the single biggest issue is having too many simultaneous priorities and those priorities being big projects with long delivery times.
‘Escaping the Build Trap’ describes it as peanut buttering:
peanut buttering: spreading too many strategic projects across too few people instead of making a concerted push in one direction.
Peanut buttering is dangerous for a company wanting to respond to customers and ultimately your success as a Product Leader:
- Lack of regular customer feedback — large initiatives result in long periods before any user gets to see results, breaking one of the key principles of user research, regularity. The aim in research is to protect development investment by reducing the chances of rejection by customers.
- Too few people to execute in a reasonable time — Large projects with long delivery periods create frustration within your user base (“why is nothing changing?” -> “we’re working on project X”). It’s tempting to move developers and product mangers into ‘UI maintenance’, further slowing projects down and reducing their eventual relevance.
- PMs distance themselves from customers to deliver — Investing in mega-projects changes the incentives for Product Managers. Instead of understanding the customer and their usage of the product, they focus on how to get a delivery out and make progress according to a project plan.
How to break the cycle
- When and how to commit is key — Committing to the delivery of the whole project makes you responsible.
- Stop, plan, slow down — Big projects are often kicked off urgently due to changes in investment or the market. In the heat of the moment, this project will seem like the only option. Commitment should happen when potential benefits and costs are clear. Give you and your teams time (measured in weeks) to work out the options, costs, uncertainties and risk. Present 3 options to leadership.
- Create a culture of delivering in small chunks — Ensure that your Product Managers and teams are planning changes that can be delivered to users in 2 week chunks. If this isn’t possible, it increases risk, which should be escalated back to management.
Let’s be mature! Plan your roadmap to customer centricity
This article gives practical, business and cultural insights on how and why it’s important for product teams to be focusing on the customer.
To put this all together and give your staff and management a view on where you want to take product development, invest in a maturity model.
Chris Avore (from NASDAQ) gives a great place to start with his organization’s design research maturity model.
References
[1] https://www.forrester.com/report/Rich-Internet-Application-Errors-To-Avoid/RES46114
[2] https://www.nea.com/blog/the-future-of-design-in-start-ups-survey-2016-results
Thank you
Huge thank you to Kira Brauda who taught me so much about the value user research and has been a huge help in getting this article to be accurate and relevant.
About me
- I help start ups grow to create fantastic products for their customers.
- I work with owners, leadership and staff to structure, improve strategy, planning and execution. See LinkedIn
- More about me: https://alexallan.tech
More of my work
- How to Be a Truly Great Product Leader: Strategy — What I wished I had known about strategy when I started in Product Leadership.
- 9 Months of Scaling Up Software Development at GotPhoto — Case study with one of my clients.
- How and why ‘technical products’ are different. Or are they? — What I learned being a PM for ‘technical products’.
