How to Be a Truly Great Product Leader: The Customer | by Alex Allan | Nov, 2022

Why do we in Product so often forget the customer? We look at how systematically focusing on the customer is vital for avoiding expensive mistakes and maximizing development ROI.

It’s all too easy for Product Managers to focus on delivery over customer outcome to detrimental business results. Companies that invest in research and design have proven improved performance.

Product Leaders have a responsibility to ensure investment in design and research, and fostering customer-centric behaviors in Product Managers.

Insights, team skills and avoiding large projects are the major aspects holding you back from getting better ROI from your development team.

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 living up to our expectations and beta testers hated our new app.

What went wrong? Delivery had taken priority over the customer.

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.

In companies working with immature agile processes, the cost of reworking existing code can be anything from 4x to 100x [3].

Investment is needed into understanding the customers and building the right product for them, to avoid making expensive mistakes.

In short:

Investment in user research decreases risk of market rejection.

As a product leader, you are responsible for what’s built and making sure that your team has the skills and resources needed to create great products.

Less mature companies are often in a constant state of feeling behind on delivery. Poor business results and previous unkept promises on delivery encourages a thinking of “we just need to deliver quicker” attitude, which puts output above outcome.

In this environment, product managers aren’t given the support or time to understand the market, its customers and their needs. 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.

When you’re in the cycle, it’ll feel like the only valid choices you can make push you further into the cycle. In fact, you have a choice.

When a company starts, the founders and first staff generally develop their product in quick iteration with potential customers. A company surviving long enough to grow is proof of transaction with 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 and end up further away from the people using the product. The company starts hiring Product Managers, who however lack the insights gained by founders and earlier staff members. 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 into minds of Product Managers — Ensure Product Managers can name the main ‘jobs to be done’ and customer painpoints.
• Start small; keep it regular — PMs meeting customers once a week. Surveys once a quarter. Get help from other departments like Customer Care and Marketing.
• Standardized user research repository — Create templates for user interviews. Store results in one place. Start simple (like Google Drive) but quickly more to a professional solution.
• Internal Product Manager hires from other departments won’t help customer insights in the long-term — They’ll bring a short-term boost to knowledge in the team but won’t provide a systematic approach. Plus new recruits will focus on learning core product skills at first.
• Buy-in from other leaders — Speak to your peers and get momentum for systematically gathering and consuming customer insights.

When I was a fresh product leader, we were rebuilding our mobile apps. The old ones were a mess; developed through hundreds of quick fixes.

Importantly, at the same time we were in the process of tripling the size of the development and product teams, meaning most staff were brand new.

As well as the code being a mess, the user experience wasn’t top notch. We knew there were UX problems but hadn’t the research to show exactly what was wrong.

We made the decision however to try to both improve the UX (without necessary insights) whilst rebuilding app.

Months go by as we rebuild fundamental parts of the user experience, finding backend and UX contradictions along the way.

The first beta goes out to users:

The verdict on our new app: confusion. Users preferred the way the old apps work.

We needed another 4 months of rework to get the app to a state where we could release and avoid having a user backlash. The rewrite had already taken a year, adding 4 months additional substantially put us over budget.

So what went wrong?

Quite simply, I had asked for the impossible. The team were asked to deliver both a new app as a technical base for future changes and an improved UI without the adequate research nor people required.

• 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…
• Pressure to fill backlogs — The Product Manager and Designer were under pressure to ensure that the developers didn’t run out of meaningful work.

A better approach in that situation would have been to focus on a rewrite to provide a technical basis for future work, whilst hiring enough support and allowing user research and design to onboard.

What’s the right balance?

It’s not just about the number of people in roles, it’s also where they come into the development cycle. User Research comes earlier in the cycle to find what the problem is, then Design to find the solution then engineers to build the solution.

How to break the cycle

• Give adequate budget — Rule of thumb would be around 20–25% (think one designer person in each team of 6 people plus research support) on usability. (Research: https://www.nngroup.com/articles/usability-roi-declining-but-still-strong/)
• Work with engineering leadership on ensuring balanced teams — adding that extra engineer who end up working on poorly researched and tested ideas won’t provide the ROI the company is looking for.
• Watch out for ‘hiring momentum’ biassing your team set up — Hiring five Engineers or Product Managers doesn’t take five times the time as hiring one. Insist on making progress on all positions even at the cost of slowing down overall recruitment.

Working in product management for the last 12 years with scale-ups, the single biggest issue is having too many simultaneous priorities and those priorities being big projects with long delivery times.

Melissa Perri describes it in the first chapter of her book ‘Escaping the Build Trap’:

peanut buttering: spreading too many strategic projects across too few people instead of making a concerted push in one direction.

• Lack of regular customer feedback — long projects 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.
• Understand the aim and expected outcome — Interview leadership about the reasons behind the change. Deeply understand and empathize with where this desire is coming from.

Assess your maturity

A great place to start is to assess where you are and develop a roadmap to maturity. Two fantastic resources:

Understand the Build Trap

Melissa Perri’s 2018 cult classic ‘Escaping the Build Trap: How Effective Product Management Creates Real Value’, explores how companies find themselves valuing output over outcome and how product management leadership can help escape the trap (affiliate link).

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

[3] https://dzone.com/articles/real-cost-change-software

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.

• 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