Processes 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.
However, a company can also be dragged down by a lack of clarity about decision-making, goals, and what's causing goals to be missed. They can be dragged down by inefficient onboarding processes. All of these conditions can cause a downward spiral of guesses, failures, frustration, and a lack of trust that leads to more guessing and so on.
Here are 8 signs that your company is on the verge of a downward spiral and how you can combine effective product development with a strong framework like Jobs-to-be-Done to rescue you.
When your company is failing to hit its growth goals, either revenue or profits, it puts a strain on every team. Revenue problems put stress on the sales team and their capabilities first. If only they could sell better, the company would 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.
To get growth back on track, the product development 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:
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.
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 like, "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?"
The HiPPO is the "Highest Paid Person's Opinion." It's a fast way to decide what should be on the roadmap, 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.
In larger companies, on the other hand, 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. 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.
Look at the Amazon Fire Phone failure as an example. Launched in 2014, it was supposed to compete with the iPhone and Android. Instead, it ended up losing $170 million in a single quarter. How? Why? Aside from being too expensive and lacking any truly innovative features, the real reason has to do with CEO Jeff Bezos taking over the design process. Bezos was responsible for managing every critical decision, a fact that ultimately frustrated his design team. The bottom line: they were building the phone for Bezos, not the customer. The HiPPO took over.
With technology progressing 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 roadmap is a virtue, but it has limits. If you find your roadmap 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 roadmap 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 roadmap changes.
You know when you put something out there, loud and proud, and all you get in response 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 counter to this 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.
As a product person, have you ever looked at a marketing campaign and thought, "Why are they promoting that?" 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 development and marketing teams that a framework can help solve.
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 roadmap, 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.
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 name popularized by 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 a 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, and the focal point of segmenting your market. 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 roadmap.
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. Contact us to learn more about product development and finding a framework that works for you.