Build Products That Your Customers Want / Build Something People Want
8 July, 2019
Head of product, Last Mile Core Driver Experience at Amazon
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
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.
Senior Director of Engineering at SupportLogic
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.
Chief Technology and Product Officer at Hive Learning
Supporting principles on why being data led (not driven) helps with the story telling.
Head of Engineering at Xero
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.
Google Cloud Practice lead at Contino
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..
VP - Engineering at ITILITE Technologies