hippo

8 Signs You Need a Product Development Framework

Process and frameworks can get a bad rap. Many companies are proud of having a light-weight or loose process, considering themselves “agile,” “fluid,” and “intuitive.” They may even say their work is like jazz and they don’t want to restrict their creativity. Most of all, teams fear that process will slow them down.

But, a company can also be dragged down by a lack of clarity: about decision-making, goals, and what’s causing goals to be missed. This condition can cause a downward spiral of guesses, failures, frustration, and a lack of trust that leads to more guessing and so on.

Here are eight signs that your company is on the verge of a downward spiral and tips on how a strong product development framework, such as Jobs-to-be-Done, can rescue you.

Sign 1: Missing Revenue and Profit Growth Goals
When your company is failing to hit its growth goals, be it revenue or profits, it puts strain on every team.

Revenue problems put stress on the sales team first. If only they could sell better, the company will earn more money.

All sales teams should aspire to be well-oiled, high-performance selling machines, but there is little they can do if the product does not satisfy customer needs better than the competition. See Wells Fargo’s recent fraudulent sales scandal as an example of how damaging it can be to put all of the revenue pressure on the sales team.

Sign 2: Disagreement on Customer Needs
To get growth back on track, the product team needs to ensure that their product is satisfying customer needs better than the competition. This raises an important question: What is a customer need?

Your product team may lack an agreed upon definition of a customer need, let alone agree on your customers’ needs.

If this is true, they’ll tend to use proxies to determine what to build:

  • Customer feature requests (“I want a faster horse.”)
  • Sales team feature requests (“I can close this deal if you’ll just build this feature.”)
  • Feature ideas from stakeholders, executives, etc. (“I love this idea. I know if we build it we’ll get growth. I can just feel it.”)
  • New technologies (“Augmented reality is the next big thing. Our customers need it!”)
  • New channels (“Everyone is on Snapchat. Our customers need us there too.”)

The problem with these proxy inputs is that they change frequently and often rapidly, which means the team is attempting to hit a moving target. A framework can provide a stable definition of customer needs.

Sign 3: Road maps Prioritized by Fierce Debate and Negotiation


How many times have you seen someone use their rhetorical prowess and passion to convince the room that a feature should be built?

How often do you hear someone refer to roadmapping as “horse trading?” Are your roadmap meetings exhausting and exasperating, with internal stakeholders jockeying to “win” the meeting by getting “their” features prioritized?

A colleague’s persuasive abilities have no bearing on the extent to which a feature idea will solve your customer’s problems.

Under the stress of such an environment, you may resort to answering easy questions, “Do I like how this feature looks?” or “Will I feel better if I give my colleague her way and get this meeting over with?” rather than the most important question, “Will this roadmap satisfy customer needs better than the competition?”

Sign 4: The HiPPO Rules
The HiPPO is the “Highest Paid Person’s Opinion.” It’s a fast way to decide what should be on the road map, but is it the best path to growth?

If the highest paid person happens to be very close to the problem you’re solving with your product, you might be in luck. When answering the question, “Do I like this?” she may do so from a frame of reference similar to your customer’s.

But, in larger companies, the highest paid person may be far removed from the customer’s problem or perhaps has never experienced it. Her primary activity could be managing people and nowhere in the job description did it say, “Must have experienced our customer’s problem.” If that’s the case, what she likes and doesn’t like could be wildly different from what’s useful to the customer.

Sign 5: Shiny New Object Syndrome Leads to The Disposable Road Map
With technological progress at a rapidly accelerating pace, you can expect exciting new technologies and channels to come on the scene very frequently. What do you do about it?

Do you let the shiny new objects steal your focus and cause you to throw out your road map? Or do you have a clear criteria for whether to adopt new capabilities or discard them as mere distractions?

Maintaining agility with your product road map is a virtue, but it has limits. If you find your road map is ripped up so often that you never finish a feature or you’re constantly releasing half-baked features that never get their planned iteration cycles, you’ve got a problem.

All this zigging and zagging will lead to a product full of elements that “sort of” work, none of which are truly great, and none of which bring value to the customer.

Chasing the shiny new objects and constantly changing the road map are indicators that your team disagrees on what the customer needs are. You’re likely using the proxies mentioned above (sales requests, new tech, etc) to determine what to build and as they change, your road map changes.

Sign 6: Launches Met with Crickets


You know when you put something out there, loud and proud, and all you get in response back is…crickets?

That can happen with a product release as well. Your team puts in a lot of hard work and gets very excited to show it to the world. The launch happens, you celebrate, and then you realize a week later that no one is using the new features in your product..

The obvious answer in this situation is “oh, the users haven’t found the feature yet. Let’s add help text or a flashing message somewhere to point it out to them.” If you do this and three weeks later there is no uptick in usage, you have a bigger problem. Either the new feature isn’t serving a customer need at all or the need it serves is already met.

Sign 7: Feuding Product and Marketing Teams
As a product person, have you ever looked at a marketing campaign and thought, “Why are they promoting that?”

And as a marketing person, have you ever read release notes and thought, “Why would a customer care about this? I guess I’ll just call out the new features.”

Or perhaps you’ve witnessed your product and marketing teams denigrating each other: “I just can’t understand what that team is doing. I don’t think they even know.”

If this sounds like a familiar pattern, you have a communication breakdown between your product and marketing teams that a framework can help solve.

Sign 8: Reinventing The Decision-Making Wheel
Last week you presented a deck with designs your stakeholders loved. Two weeks ago you assessed the impact of a new idea on your team’s KPIs. Three weeks ago the executives were compelled by the user problem and approved your plan.

To prepare for the next defense of your road map, you’ve been meeting individually with various stakeholders, trying to determine what’s on their minds.

If the criteria for decision-making is constantly shifting and needs to be divined from tea leaves, you could really use a framework.


The Solution
A product development framework like Jobs-to-be-Done can prevent the downward spiral of guessing, missing goals, growing frustrations, negotiations, more guessing, etc.

The key idea behind Jobs-to-be-Done, a framework based on the theory of the same namepopularized Clayton Christensen, is that your customers are not actually buying your product, they are hiring it to get a job done. This is important because your customer’s struggle with the job is what causes them to look for a product and make purchase.

In Jobs-to-be-Done, customer needs are a precise articulation of that struggle. Needs are the metrics customers use to judge how well they can execute the job. Since people want to get the job done quickly and accurately, customer needs are written in terms of time and likelihood. For example, drivers who want to reach a destination on time (a job-to-be-done) need to “reduce the time it takes to determine if they should take an alternate route due to traffic conditions” and “reduce the likelihood that recent road modifications are not considered when setting the route.” Those are two customer needs in the job that are stable and the team can target with their road map.

This brings us to a key question: What does it mean to satisfy the need “better” than the competition?

Now that we’ve defined needs as metrics of speed and accuracy, “better” is easy to define and detect. The solution that meets the need faster and more accurately is “better,” i.e. it will deliver more customer satisfaction.

If the product team delivers solutions that meet the needs in the job faster and more accurately than the competition, people will use the product and put growth back on track. Marketing the product becomes easier as the features are designed with the customer benefit in mind at the start, which can be promoted at launch.

With Jobs-to-be-Done, the team gains alignment around satisfying customer needs, which leads to hitting growth goals. This customer-centric approach minimizes internal debate and negotiation because it raises the conversation away from individuals’ goals and their products to how groups work together to resolve a customer’s job faster and more efficiently. It puts the focus on your customer’s goals and assumes that if you deliver against them, everyone in the company will hit their own goals.

Your team will have common goals, common metric-driven means of evaluating proposals, and a common language with which to discuss it, decreasing the conflict and the ferocity of the debate and negotiation in the roadmapping room.

When you adopt Jobs-to-be-Done at your company, decision-making meetings can get pretty boring. The criteria is almost always “does the proposition on the table satisfy the targeted customer need in the job better than the competition?” You may have an interesting conversation about what you can do to have an even better idea, but the criteria remain the same.

If you’ve seen one or more of the above signs at your company, you’re not alone. Many teams have experienced these problems. Fortunately, there is a solution. Find a framework that works for you. And contact us at thrv.

JTBD Product Management: An Education Market Example, Part 3. Road Mapping, Aligning the Team, & Scoping an MVP

This week features the third and final installment of our JTBD Product Management: An Education Market Example series. If you haven’t read them already, check out Part 1, Part 2, and our Cheat Sheet. With this series, we’re presenting you with an overview of how the Jobs-to-be-Done framework can help you view product management and product development through a different lens – one which focuses on the customer, the job they are trying to get done, and their unmet needs.

We’ve been using the educational publishing industry in order to bring this thinking to life, but the ideas presented here can be applied to any industry where you’re tasked with creating new products, or new features to existing products.

In today’s post we’ll talk about how to prioritize your road map, align your team and develop your minimum viable product.

Prioritization

When you spend all day, every day thinking about your product, it’s only natural that your success metrics will be product-centric. For example, if you’re building an education app road map, you might optimize for an increase in “time spent in app” or “frequency of sessions.” Any feature that would make these metrics go up would be high priority.

However, if you’ve read the previous entries in this series you know that the customer’s satisfaction with getting the job done is your ultimate target. When developing a road map, Product Managers using Jobs-to-be-Done prioritize features that serve the most important and least satisfied customer needs.

If we’re working on the job “learn a subject,” we might find that “minimizing the likelihood of having a question that can’t be answered in the moment” is very important and not satisfied. Interestingly, a feature serving this need might cause users to spend less time in our educational app because more of their questions are answered right away and they are learning the subject faster. The app is increasing value for the customer even though a commonly used KPI is decreasing.

Prioritizing by customer needs leads to releases that deliver value to users and avoids those that could be great for the business but irrelevant to the users.

Align Team

Designing, developing and bringing a new product to market requires a team of skilled individuals who are committed and focused on a common goal. You’re going to be challenged with a host of difficult decisions from feature prioritization to scope to where to invest resources. Even the best teams can be challenged by these situations, especially when the time for discussion ends and choices need to be made.

All too often, this is when the course is determined not by data, but by The Boss, who makes a suggestion that’s really more of a directive. Since she’s in charge, the HIPPO (HIghest Paid Person’s Opinion) rules. As a result, your team is left in a state of frustration. Everyone is left to argue for their ideas on what to prioritize and the result is time and money wasted, a dysfunctional team, and customers who are potentially confused by or unsatisfied with your product.

So, how do you get team alignment? By removing the personal and focusing on the measurable. When you measure things like speed and accuracy, you eliminate opinion or hunches. If the research shows that students learning algebra have an unmet need to “reduce the time it takes to learn how to factor quadratic equations” and it currently takes days, everyone can get behind an idea that reduces that time to hours or even less. When you align the team around customer needs, opinions matter a lot less.

Scope MVP

The idea of delivering a minimum viable product to market as fast as possible is so widely accepted, it’s nearly conventional wisdom. But, how do you know which features belong in the MVP? What makes your product viable?

You and your team may bring years of training and experience to the task so you could rely on intuition. Or you could attempt to estimate the impact on your business and include the features that will generate pageviews or time spent in your app or repeat visits–whatever your KPIs are. Or you could show the MVP to your customers and say, “Do you like this?” If they say, “yes,” are you ready to go?

When scoping your MVP, Jobs-to-be-Done thinking prompts the question, “What features will have the most impact on my customer’s needs?” For example, Britannica may have shown new editions of its encyclopedia with “even more volumes” to its customers. They may have said, “Great! We love information. Bring on more volumes!”

But do the extra volumes help reduce the likelihood that a student’s question can be answered in the moment? Does it reduce the time it takes to find the definition of an unfamiliar word?

“Liking” a product is not the same as having it serve your needs much better than previous solutions.

Jobs-to-be-Done assumes if you create value for your customer, value for your business will follow. The features that belong in your MVP are those that serve at least one important and unsatisfied customer need. It’s best if your MVP meets the most underserved need i.e. the one with the highest opportunity score. If your MVP doesn’t serve an unmet need, you’re not ready to ship. If your MVP includes features aligned with over-served needs, you may have to re-think your roadmap.


That wraps up our JTBD Product Management introductory series. We hope you’ve found it informative and that it has sparked questions, such as “Is our company defining our market as a product or a job?” “Is someone out there getting our job done better with a different product?” “Do we agree on what a customer need is and does our MVP meet at least one?”

If you feel you could benefit from implementing the thrv approach, get in touch with us. We’d love to talk with you about how our products and services can help you launch high growth products. Be sure to check the thrv blog regularly for more ideas, stories and insights on how to implement the Jobs-to-be-Done framework.