Deliver Outcomes, Not Features

Guest Post by: Jie Jin (Mentee, Session 5, The Product Mentor) [Paired with Mentor, Andy Wadhwa]

The learning experience in the past few months with my mentor Andy Wadhwa has been profound. If I could pick just one thing to share, it would be: focus on delivering outcomes, not features.

I vividly remember the first conversation with Andy. At the time, our product team was in a process of envisioning our ideal product. We were stuck. The big vision was clearly overwhelming – we wanted to change how customers interact on the site; we wanted to build the brand new structure to support a new type of customers, to build the internal admin functions to facilitate internal efficiency; and we wanted to holistically rethink everything to link all the above components. On the other hand, we knew that no matter how logical our thinking was and how beautiful this grand architecture seemed, the reality would change quickly and the carefully architected plan would quickly go obsolete in just a few months. So should we keep going with this route until we had a perfect and detailed product vision, or should we abandon this idea and reroute?

I shared with Andy our situation and my struggle. Before getting into any details, Andy asked – What is your company goal? What problems are you trying to solve by doing this product envisioning exercise? I stuttered – currently our company goal is to increase marketplace liquidity, but this exercise is not directly tied to the goal.. we are not trying to just solve any specific problem…we want to solve all the problems…. Just by hearing myself say that, I realized there was a problem in our approach.

The problem was that instead of examining the current company priority goals and identifying what we should build to achieve these goals, we started the vision exercise first with what we wanted to ship, i.e. detailed illustrations of ideal user flows for all types of customers. Then further reflecting on our day to day operations within the product team, I realized that oftentimes we were taking orders, i.e. requests from other teams or sometimes directly from our clients; request prioritization then meant we looked at these “given requests” and prioritized them against each other. In other words, we started with looking at what features we could work on, rather than what we should build to deliver the outcomes. We were heads down busy delivering features but ended up not really knowing which feature pushed which metric. This also made it hard for us to evaluate features and decide what features to keep or remove down the road. For a startup like us, it was nerve racking to think that we are not always directing the very limited resources to drive outcomes – not just a waste of scarce resources, but high opportunity costs.

To internalize the principle of focusing on delivering outcomes rather than features, I’ve learned to pick up following tactics.

Start with clear company goals.

I’ve practiced to always remind myself of company goals as I jump onto a project, review a request, or write up a product requirement document. If we want to focus on delivering outcomes, we need to have in mind what outcomes mean. Keeping the goals on top of mind has helped me stay laser focused on the direction that we aim for. It has also helped me see the line between priorities and distractions more clearly when it comes to evaluate specific product opportunities or features – I feel more comfortable and confident saying no to features that do not contribute to achieving the goals.

However, having clearly articulated company goals in place may not always be the case. Afterall, shipping features may bring more instant gratifications than goal setting conversations would. Oftentimes, the problem is not that we don’t have a goal, but rather having too many goals. But the reality is that for startups like us who are constantly under severe resource constraints, likely we only have capacity to solve one big problem well at a time. At the end of the day, it is about prioritizing goals and problems we want to focus on at a particular moment and articulate exactly what the goal is. If company goals are not clearly articulated in your context, I suggest approaching leadership for more clarity or helping facilitate a company-wide discussion to better articulate the goals.

At the product request or feature level, always ask what problem we are trying to solve and why solving this problem matters.

We receive feature requests all the time. Focusing on delivering outcomes means that, at this feature level, we need to dig into the root problem that each feature request is trying to address. Only if we have clarity about the root problems, can we properly ask the next question – is the problem we are about to solve really matters to achieving the goal? Not all problems are equal. Here’s a great analogy I’ve learned from my mentor – by delivering the solution to customers, are we offering a painkiller that they can’t live without or vitamin C supplements? In other words, are we addressing a critical pain point or an issue that may or may not exist? Surely we want to provide painkillers rather than vitamin C pills when the customers have obvious pain points.

It’s also worth noting the difference between solutions and problems. Sometimes solutions are disguised as problems, making it confusing to dig up the real problems. An example I often remind myself to revisit is:

I need a cup of coffee v.s. I can’t wake up in the morning.

“I need a cup of coffee” sounds like a need. But if you dig deeper, you’ll find that my real need or problem is to wake up in the morning. Assuming my higher level goal is to have a caffeine free healthy routine – without digging deeper, you would dismiss my “coffee” request because it doesn’t align with my goal. However, if you find out my real problem is to wake up in the morning, you’d more likely consider (hopefully) my request and come up with all kinds of solutions that are aligned with my goal (and hopefully you’d also consider my love for coffee).

My favourite tactic to dig into the underlying problems is the “five whys” technique. Here’s another article about asking questions in customer interviews to really understand their underlying pain points.

A mindset shift: failure is a choice.

Up until now, we’ve talked at length about articulating goals and assessing outcomes against goals. In this process, it is critical to define the goals and outcomes in a measurable way. I like to think about defining measurable goals and outcomes as creating the operational definitions in scientific experiments. I think technically, defining success measurements is not the most difficult task. The bigger challenge I’ve encountered is anxiety from the team around making arbitrary goals and not being able to hit it. A mindset shift that has been helpful to me is to look at failure as a choice rather than a judgement.

Failure is not when we don’t hit the goal that we’ve defined upfront. Failure is when we go into a product decision not knowing whether we’re right or wrong. If we don’t hit the target but have gained more clarity about where to go next, that’s learning. As problem solvers, it is up to us which type of failure we are open to embracing and which type of gain we go after.

Jie picked up the product manager role in 2015, after several years helping Catchafire, a startup social enterprise build its operations from the ground up. Known as the “why kid” by her coworkers and friends, she has great passion for meaningful problem solving, habit hacking, and everything about building smart, healthy, sustainable agriculture and food systems. A Chinese native, Jie holds an M.S. in Social Work from Columbia University and a B.S. in Psychology from East China Normal University.

 

 

More About The Product Mentor

The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

• Conducting regular 1-on-1 mentor-mentee chats
• Sharing experiences with the larger Product community
• Participating in live-streamed product management lessons and Q&A
• Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy