Lifting the Feature Factory Boulder

“Product teams should stop prioritizing solutions and instead prioritize opportunities. When we are judged by what outcomes we drive, it’s less about what solutions we deliver and more about what problems we solve for our customers.” — Teresa Torres

These two sentences hit me like a ton of bricks. Why? Like many at large, traditional corporations, I work in an organization with a strong “feature factory” culture. That is, prioritization and praise tend to follow output more than they do outcomes. Yes, we have a general understanding of the business lever our products drive — direct revenue, indirect revenue, productivity savings; but when it comes to day-to-day conversations and decisions, we’re thinking and talking about features.

Before I dive too deep into this topic, though, a little bit about myself and where I work.

I am a Senior Manager of Product Management at GE Healthcare. I started in one of GE’s rotational leadership programs and now manage a team of product managers that build the core components of GE Healthcare’s customer-facing web and mobile experiences. I am passionate about modern product management and love getting to coach my team on new ways of working!

For context, GE, has been in business since 1892. I say this not to provide a history lesson, but to highlight that GE is a very big company with established ways of working. Transformation is hard at any company, but when transformation needs to happen at scale — across a complex matrix of regions, product lines, and functions — well, that’s XL hard if we’re t-shirt sizing it. Or as Donkey would say, that’s a nice, big, fat boulder.

How output-oriented environments manifest themselves

Output-oriented questions and tasks are all around us. Below are a few examples I experience on a regular basis.

· A stakeholder says that he needs X feature added to the roadmap and wants to know when it can be slotted

· To summarize a quarter’s achievements, I’m asked to fill out a template listing the features I delivered

· I’m asked to fill out a spreadsheet with the epics I have planned for 2021 along with how much it will cost

In the first example, the stakeholder makes no mention of why he needs feature X or what problem he anticipates feature X will solve. In the second two examples, I’m asked for what deliverables I have/will deliver. I’m not asked about the problems I’ve solved or the broader impact this has made to the business. All are evidence of the feature factory culture I touched on earlier.

So why is this a problem?

In my experience, when we operate in an output-oriented environment, one of three things happen:

· We end up building something that doesn’t solve the problem because we never truly understood the problem

· We end up solving the problem, but in a less than optimal way because we never explored other potential solutions

· We end up solving the problem, but it ended up not being the right problem to solve

All three of these scenarios result in waste and a less effective product.

What to do? How to start shifting towards outcome-oriented thinking?

Let’s take the first example of how output-oriented environments manifest themselves and walk through how we might counter this.

A stakeholder says that he needs X feature added to the roadmap and wants to know when it can be slotted

Counter: Walk through an opportunity solution tree together with your stakeholder to achieve the following:

1. Understand the opportunity, i.e. why the stakeholder is asking for this feature. What business outcome is the stakeholder looking to drive? What is the need, pain point, or desire from the end user’s perspective? What change will be observed if the problem is solved?

2. Once defined, evaluate whether the opportunity aligns with your product’s vision and target outcomes. That is, does it make sense for your product to go after this problem?

3. Once the opportunity is prioritized (remember, this may not be the best opportunity to tackle at the moment), ideate additional ways you might solve the problem.

Example

One of our stakeholders recently approached the PM on my team who manages support for our digital experiences, asking that we add chat to our global websites.

1. Understand the opportunity, i.e. why the stakeholder is asking for this feature. What business outcome is the stakeholder looking to drive? What is the need, pain point, or desire from the end user’s perspective? What change will be observed if the problem is solved?

In this instance, our stakeholder was looking to increase the number of web-driven leads by offering customers a more convenient, real-time support channel. Through customer research, we learned that the pain point experienced by our customers was a slow response to their questions as they evaluated a potential purchase.

2. Once defined, evaluate whether the opportunity aligns with your product’s vision/mission and target outcomes. That is, does it make sense for your product to go after this problem?

The mission of our support product component is to provide faster resolution (24 hours or less) to our customer’s questions and issues in order to enhance their experience. There are several business outcomes that we are looking to drive by doing this, but for commercial related questions, the key outcome is to drive leads and ultimately, conversion to purchase.

With this in mind, yes, it makes sense for our product team to go after the problem presented by this stakeholder.

3. Once the opportunity is prioritized (remember, this may not be the best opportunity to tackle at the moment), ideate additional ways you might solve the problem.

Is providing our customers with a chat feature the best way to provide a timely answer to their questions? To answer this, I like to reframe the problem as a “How might we” — How might we provide our customers with a faster response to their product questions?

Together with my stakeholder, tech lead, UX lead, and other key members of the product team, we brainstorm against this question. Our map may look something like the below.

From here, I like to use a simple impact/effort matrix to determine the best idea to pursue. Note, based on the impact of the problem, we may also want to do additional customer research before selecting a solution.

I’ve found that by including the stakeholder in the above activities, he/she is more likely to understand and accept why their suggestion is or isn’t prioritized because they were a part of the process that led to the decision.

Let’s wrap it up

At the end of the day, stakeholders and product teams alike all want what’s best for our customers and business. We know that it’s the outcome that matters and not the output. In recognizing that we all have different ideas on how to best achieve our target outcome and bringing these differences to light using the above framework, I guarantee you will start to lift the big, fat feature factory boulder.

I’d love to hear your thoughts and feedback on this article (it is my first!). Also, if you know of a product leader who is also faced with moving the feature factory boulder, please send this their way.