Back to resources

Build Products That Your Customers Want / Build Something People Want

Product
Productivity
Team Processes

8 July, 2019

Pei-Chin Wang

Pei-Chin Wang

Head of product, Last Mile Core Driver Experience at Amazon

Pei-Chin Wang shares how her product team wasn’t always building what matters to the customers and how she created a simple framework that stayed true to her customers and the organization’s principles.

Problem

The organization that I currently work for is a customer-centric company. When I joined three years ago, there was a bit of perception that the products being built by the product team weren't always relevant, that they weren't making a difference to the customers. Our product managers had great ideas but there wasn't a clear guiding principle of what should be built and why. So I had to determine if the products being built mattered and if they would make a difference to our customers.

Actions taken

I installed a fairly simple framework. At our weekly product design working sessions- where we talk about any new things that we want to build- I would repeatedly ask the team the following three questions:

  • What is the customer problem that we are trying to solve?
  • Is this an important problem?
  • Does the solution actually solve the customer problem? In the beginning, people didn't quite understand why I was asking those questions, so we went through and broke down about each one. First, I defined the customer problem as known problems or unmet needs for our customers, a pain point that we can validate as opposed to a problem that our product managers imagine. We spent about 2-3 months calibrating exactly what a customer problem was and how to use user research to validate it as a customer problem. Next, we talked about how important that customer problem was. And once we were on the same page about how to answer those first two questions then it became a lot easier to take on the last question. So lastly we would come up with a bunch of solutions to resolve the customer problem. After a few months of me pushing through the concept of the framework, it became a habit of the team to want to solve customer problems. The proof was in the pudding when during one of our working sessions a member of the team asked the first question without me having to say anything. It was a great feeling of accomplishment.

Lessons learned

  • I think that it has been working so well for the past couple of years because it is simple. It may have taken six months for the organization to start adopting its principles, but now it is ingrained in our product development philosophy. Anyone on the team can ask the questions and fairly determine if what they are pitching is relevant or not.
  • Because the framework that I created has become so ingrained in our cultural DNA, now whenever a new PM or IC joins the team they are immediately placed in an environment revolved around solving the customer problem.
  • The questions have a customer-centric point of view. It's not about blindly driving business growth or developing based on unvalidated assumptions.
  • Now that the team has adopted the customer problem mindset, I am looking to graduate the framework to the next level by adding another question: How do we create an obviously better experience for the customer. It's a work in progress, but I'm looking to broaden our answers to solving the customer problem.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Hosting a successful internal hackathon with < $6k budget

6 February

Internal Hackathons invite team spirit and collaboration which are critical whether an engineering org is co-located or operating remotely spread across 20 times zones. Hackathons give employees the opportunity to connect and network while they solve fun & relevant challenges.

Company Culture
Team Processes
Balki Kodarapu

Balki Kodarapu

Senior Director of Engineering at SupportLogic

"You don't care about quality" A story of single metric bias

3 February

This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.

Product Team
Productivity
Team Reaction
Alex Shaw

Alex Shaw

Chief Technology and Product Officer at Hive Learning

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

How to measure Engineering Productivity?

30 November

When you grow fast, its normal to focus on Value delivery aka "Feature Releases". Too many releases too soon will inevitably lead to piling tech debts and before you know, inefficiencies creep in, performances goes down, and ultimately any new release takes too long. Sounds familiar? Then read on..

Productivity
Prioritization
Performance
Ramkumar Sundarakalatharan

Ramkumar Sundarakalatharan

VP - Engineering at ITILITE Technologies