Join the Product Rebellion

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

Let’s face it, we all have naysayers in our organizations. Naysayers are strong influencers who object no matter what, think they have a better idea, or believe an alternative option is the right path. And sometimes that alternative path won’t be one of the primary options already being considered and analyzed. It happens. And some of these influential naysayers can derail the decision process. These folks have to be addressed to get broad commitment.

But there’s hope. We use the following list of good practices:

1. Identify any highly influential naysayers who could derail the decision-making process. 

They may or may not be a person who must be primarily consulted, but they hold strong influence in the company. We’ve seen tenured engineers, senior leaders of non-impacted organizational functions, board members, and investors be naysayers. They could have the ear of the CEO, your executive leader, or your CTO.

2. Understand their point of view. 

A simple feedback gathering session might be in order. Trial ballooning a proposed decision is a good way of getting their point of view. Understand what their objection or their desired path is and why.

3. Use data. 

When possible, to do a quick thought exercise on what the path they suggest looks like, asking these questions:

• How does their idea or path measure up to the criteria you are using to decide? Evaluate it with any data you have available.
• What are the critical dependencies (e.g., technical, manufacturing, political, resourcing) in executing their idea or path?
• What would you have to prioritize in the product (e.g., features, infrastructure, roadmap items) to make their path successful and how does that differ from the proposed decision path?
• Are there other, possibly unforeseen, operational requirements for their path (e.g., marketing, support, operations)?

These are questions you should already be asking of the obvious options in your decision, but they are important to ask as they relate to the strong naysayer’s path as well. Don’t make this a huge, time-consuming expedition. We don’t usually spend more than a 30-minute discussion and a 30-minute thought exercise fleshing through their desired path to understand the implications it has, building a case as to why it isn’t the right thing to do considering the criteria at hand. Or maybe it is? There have been times when their perspectives bring new thinking to the table that must be considered.

Always anticipate who your most influential naysayers will be and gather the information you need to understand their perspective. Do quick due diligence to understand what it would take to execute their presumed path so that you can confidently speak to it. It not only ensures you haven’t missed anything, but it also shows the naysayer that you are thinking broadly and considering all options, not just what you are proposing, makes them feel heard, and sets you up for a much higher probability of commitment.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

This is for any product person that has felt the frustration of overturned or unnecessarily delayed product decisions. We’ve all been there. Check it out.

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. Buy it now from Amazon.

Your job as a product person is to be a thought leader and to execute effectively. It’s a unique challenge that only a few functional roles within a company experience. As product leaders, we must influence and gain commitment across multiple functions and leaders; and usually, none of them report directly to you. 

This unique aspect of our job is partly what makes being a product person so fun (and exhausting at times)! So, we would be remiss if we didn’t discuss gaining commitment across complex organizations as one of the most critical practices a product leader should master. Whether you are a chief product officer or new product manager, proficiency in this practice dictates your success.

Getting commitment is required as the first step when implementing any strategy or product decision, big or small. Without commitment, agreement is moot. Commitment is something that many people in business, and in life, don’t understand and are caught off guard by when they realize they never had it. We define Commitment as:

A state in which the decision-maker(s) and critical stakeholders intend to and follow through on making the accommodations necessary to implement a decision while holding themselves accountable for their part in the success of the project, regardless of whether they agree with the decision.

Let’s break this down.

What do we mean by critical stakeholders? 

These are the business people who will be significantly impacted by the decision; not customers—you’ve already done the Groundwork to propose a product decision that meets your customer’s needs. Stakeholders are people like operational partners (internal and external), your development team, your manufacturing partners, your support team, and so on. These are the folks who have to take action in order to ensure success of the project.

What do we mean by the necessary accommodations? 

This could be anything required to execute, such as funding, human resources, operational or technical tradeoffs. 

The last part of our definition of commitment is important. 

We want to get to a situation where people may not agree with the decision, but they are committed to it because they understand how the decision was made and why. In this section, we talk about the elements involved in giving you the best chance of getting commitment on decisions: collecting the data required, presenting your case, and pressure testing commitment.

Getting commitment is very different from getting a head nod in the meeting where you propose a product decision. Many times, the head nod of agreement is taken as a “go.” But we all know that a lot happens after people walk out of a meeting. People are bombarded by inputs from others, conflicting priorities, and shiny objects that potentially change a head nod to an eventual head shake.

Sometimes getting commitment doesn’t mean you’ll get a consensus. If you strive for consensus, you could be waiting a long time. Some cultures require consensus. And to those of you working in those cultures, our hat’s off to you. We respect anyone that perseveres through consensus-building even at the cost of progress. There is a better way.

Instead of consensus, strive for a shared vision (we touched on this earlier in the book) of the data and in light of the decision, get a commitment to the actions required to be successful. Shared vision sounds like corporate jargon, we realize. But as you already know, it’s a concept that has stuck with us in our careers, because of how powerful it is. We strive for everyone impacted by a decision to understand how we got to a decision, versus just telling them what the decision is. We do this by communicating compellingly clear logic, data, and customer insight, all of which we obtain through the Groundwork and Practices we’ve explained up to this point.

The next time you see a lot of head nods in a meeting, do a double take and make sure you actually have a shared vision and a commitment on the actions that will result from the decision.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

In this excerpt we focus on how our practice of Scrappy Research dramatically changes the time-to-value for research and therefore the efficiency of the overall product creation process; making confident decisions quickly and often. For more on how to establish a practice in Scrappy Research, pick up the book!

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. Buy it now from Amazon.

Scrappy research is a practice that turns product managers into great leaders. Let’s talk about some reasons why.

Scrappy Research Prevents a Significant Amount of Rework

How many times a day do you make decisions about a product: feature prioritization, backlog cuts, design decisions, strategy decisions, and so on? Product people make scads of decisions every day based on intuition and whatever data they have (which can be none, depending on how big or how new the product or business is). Is it the best-kept secret that product people probably make most of their daily decisions based on gut feelings? Nope. That is our life as product people. Take this example:

Product Team A decides to build one feature instead of another based on what they think is the right direction. They build it with tracking so they can get usage data in real time. Within 6 weeks of releasing the functionality, they learn that the feature isn’t used as much as they expected, and the desired business outcome isn’t being achieved. The team reworked the functionality and relaunched within 12 weeks.

On the surface this may look fantastic: They implemented tracking, they learned within 6 weeks, and had a new version out in three months. These are huge accomplishments for some companies, but we’re here to tell you that this is an unacceptable cost of time and rework.

Keep this quote by Thomas Gilb, famous for improving an organizations’ delivery capability through systems engineering, cemented in your mind: “Once a system is in development, correcting a problem costs 10 times as much as fixing the same problem in design. If the system has been released, it costs 100 times as much relative to fixing in design.”

Scrappy research combined with a clear hypothesis is a catalyst for reducing work. To drive faster success at a significantly lower cost, make scrappy research an ongoing habit instead of a special occasion.

Scrappy Research Enables Durable Decisions

Every product manager experiences an overturned product decision at least once in their career. We’ve all been there. It’s frustrating. In some cases, we’ve seen that when product decisions are consistently overturned, it ends a career. Here’s an example: 

Product Manager A proposes a direction for a product to his leader and cross-functional partners. The product manager bases the logic behind his proposed direction on some big hypotheses, but he feels confident the hypotheses will prove correct, given what his customer service team has told him. In the proposal meeting, the cross-functional team seems a bit skeptical, but they all walk out of the room nodding and the development team gets to work. Two weeks later his leader calls him and says, “We need to pause work on this because your cross-functional counterpart isn’t supportive of the direction and expects a different direction instead…and I think I might agree. Let’s change direction.”

Replace the word “direction” here with “feature,” “design change,” or “product trade-off.” We’ve all been through a similar scenario at one time or another. Other people’s opinions start to take over and you’re stuck in the middle. For those of you who experience this as a norm, which it is in some business cultures, listen up—conducting scrappy research as a practice is for you. Whenever you need to change direction, implement a new feature, update prioritization of initiatives, or anything that you know may differ from the expectations your product team holds today, communicate your logic through customer-backed reasoning.

Scrappy research allows the customer to speak in lieu of anyone’s opinion. Practicing ongoing customer research, albeit scrappy, builds customer-backed logic that your team can understand and commit to. You may not get a consensus on your decision, but you’ll get commitment because they understand the logic behind it. We call that shared vision. Yes, it sounds like bogus corporate jargon. We learned it early on in our careers from Steve Bennett, a former CEO of Intuit, whom we both worked under. And it’s one of the only corporate jargon terms we embraced. We love the term because it represents something more powerful than “consensus.” Shared vision is our way of driving commitment. We could write an entire book on the importance of shared vision, but the point here is to get away from opinion and use customer-backed logic to communicate and gain commitment to proposed decisions.

Scrappy Research Keeps You Close to the Customer

This isn’t a goal of scrappy research in and of itself, but it sure makes you a far more effective product person. You can make faster product decisions, gain the trust of your entire team and your cross-functional stakeholders, and feel more confident in your day-to-day operating role. It’s win-win-win.

We can’t tell you how many times we see product managers deferring customer understanding to others—researchers, business analysts, UX designers. Deferring is convenient and allows you to pile other stuff on your plate. And yes, it looks like you’re making the right work prioritization decision initially, but you’re probably not.

People distance themselves from their customers and spin their wheels with decision vacillation because the loudest opinion in the room generally wins. They can’t effectively prioritize the backlog, they add a constant barrage of shiny objects, and they have no way to justify tradeoffs with confidence. All in all, the other stuff that you pile on your plate becomes significantly more time consuming. Scrappy research is not a full-time job, but it’s a fundamental practice that makes or breaks a product person’s career over time.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

This excerpt provides a little glimpse into how we’ve gotten our extended teams working in unison by expanding the access and participation in customer research. There’s lots more where this comes from! Take a look.

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

Your job as a product leader is to infuse customer insights into the broader team’s work, not just present the personas. As a reminder, a persona is a user archetype created based on your research that represents how someone might use your service, product, site, or brand. It’s about your ability to help the team get to know the persona as a person and to enable them to stand in the shoes of this person while doing their job. We’ve observed, through years of experience, that the deeper our extended team’s understanding of the customer, the less we have to rehash requirements for the project and the less rework we see.

Back in the late 1990s, when both of us were at Intuit, Heather was on the QuickBooks team and Vidya was on the TurboTax team. We were just implementing the concept of Follow Me Home across the company. This was a form of ethnographic research where we conducted onsite observational research sessions. We’d go to our customer’s place of work or place of filling out their taxes and quietly observe the process of managing finances or taxes.

The QuickBooks team conducted a bunch of these Follow Me Home sessions with small businesses and invited our engineers to observe. There was an interesting side effect of this. We found these engineers going home on a Friday after seeing and hearing these customers firsthand, and coming back on Monday having fixed an issue they observed in one of the sessions. They were so excited (and frustrated) by what they saw during the observational session that they couldn’t help but try and make the users’ experience better. We were seeing things like this across the company. The point is that seeing and hearing your target customer is by far more valuable than reading any documented persona. 

There are a couple of things to consider in achieving this kind of intimacy and motivation:

Get your extended team participating in the research whenever possible. 

Observing everything firsthand is far superior to waiting to get the CliffsNotes version. It’s not always possible, but you’ll get the best outcomes if the majority of your extended team has seen and heard your target users through observation or interaction. If they can’t participate, then organize ways for them to view or listen to the recordings of your interactions. Brown bag lunch, anyone?

Debrief the team on what you all learned through the research before putting pen to paper to write the persona. 

Make them feel just as much ownership over the persona as you do. The more ownership they feel, the more they will utilize personas; ensuring consistency and delight in the user experience they are all working hard to develop. 

Share what you learned first. 

When you learn something new through research that leads to an evolution of the persona, make sure you share the learning before reposting a new version of the persona. Focus on the infusion of learning about the persona and the implication of that learning on what the team is working on. Focus on this more than on presentation of the persona.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

As a follow on to our last blog post, we wanted to provide an excerpt that revealed how to identify the areas of the business for which you need to formulate hypotheses in order to test and build confidence in your product direction or pivot where you need to earlier rather than later. Check this out.

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

As product leaders, we spend a lot of time in meetings sharing opinions when we review customer research. We make a lot of assumptions, and we tend to hear what we want to hear. We’re sure you’ve been in more than one meeting like this. Many companies are so execution-focused that they move from one activity to another, without taking the time to help teams align, ask the right questions, and facilitate real collaboration.

Instead of just providing feedback on a hypothesis (or rejecting it outright), we’ve created three easy steps to help you coach your team to getting to a strong hypothesis: 

1. Identify What You Don’t Know

The best way to avoid some of the pitfalls we described earlier is to think about what you truly don’t know about the customer or problem. 

• What are you guessing at or making assumptions about, with regard to their behaviors, their needs or the problem they’re facing? 
• What conditions would have to be true for a new feature to work? 
• If this is a new market, then what conditions need to be true for you to launch? 
• If this is for a physical product, what conditions must exist for a customer to successfully use it?
• What assumptions are you making about your persona, that if proven false, would dramatically change your course of action? 
• Have you accurately translated what a customer has told you they wanted into a need?

Each of these questions represent the types of assumptions we make every day. Most of the time we jump straight from idea or insight, right into development. This stage requires you to painstakingly face everything that might go wrong. We often start with asking ourselves the question “What would make this idea fail?”

Now write down everything you don’t know as a question. Here are two assumptions we made based on our fitness app Melanie Persona:

● Melanie loves to try new forms of exercise.

● Melanie won’t care if she can’t go to the same studio more than three times a month.

Those assumptions matter. We believe them to be true because we spent a lot of time talking with her, to develop our Actionable Persona. Both of these assumptions were driving major design decisions. We’re taking this head-on, leaning into the biggest assumptions that will impact our business model. What we learn will help us make an important product decision.

2. Prioritize Assumptions.

If you do step one thoroughly, you’re going to end up with a lot of assumptions. Not all of the assumptions are critical and you want to know which will have the most impact on your business. We turn to a design thinking technique called a “bullseye diagram” to help sort through and classify all these assumptions. We like to make this a visual exercise that the entire team can participate in. On a large whiteboard draw three concentric circles, each one bigger than the last. Write each of your assumptions on separate Post-it Notes so you can move them around easily. Now it’s time to prioritize.

You can place one assumption in the innermost circle. In the next circle, you get to place three assumptions, and in the outermost ring, you get a choice of five assumptions. As you pick up each assumption, ask “how important is it to know this?” You can also set up multiple bullseye diagrams and have each member of your team run through the prioritization process individually, and then gather to compare results. 

We’ve even invited key stakeholders in our business to participate so that we get to hear their thoughts and concerns. Consider what different perspectives you may want as you try to understand what’s most important for you to learn. As an added benefit, it keeps everyone on the same page and increases commitment to, and interest in, the research you’re about to start. With this exercise, you’ll have a list of prioritized assumptions—and a clear winner. This winning assumption is used for the first hypothesis you write.

3. Convert Assumptions to Hypotheses

This step converts the prioritized assumption into a hypothesis. Here’s a hypothesis format you can use:

If… [specific, repeatable action]

Then… [expected, measurable outcome]

Because… [clearly stated assumption]

The easiest way we’ve found to create a strong hypothesis is to start with your desired outcome. What needs to be true to resolve your assumption? 

• Do you want 10% more sign-ups to your site? 
• Do you want 25% fewer customer calls? 
• Do you want to increase your NPS by 5 points? 

Whether it’s 5 points or 10 points of NPS you’re trying to impact, or 25% less customer contacts; pick a figure that is meaningful to the business and will make a difference. Start with your desired outcome and then pick the appropriate measurement.

Next, move to the clearly stated, highest-priority assumption. This is where you can rewrite and reshape your assumption. If you truly believe you can’t make a significant difference by addressing this assumption, then move to your next ring of assumptions. There is no point in trying to create a test for an assumption that you don’t believe you can tackle. This is where you need a strong understanding of your business, your customers, and your market. Know what is important, and drive to make an impact where it counts.

Finally, consider the test itself. What action do you believe will create a significant result? Do you need to make a change to how people sign-up for your service? Do you need to introduce a new offering? Do you need to increase loyalty with existing customers?

Going back to the Melanie persona, share your highest prioritized assumption. One that we believe is critical to our business is: Melanie loves to try new forms of exercise.

We believe that Melanie will love to try new forms of exercise. If that is true, we’re going to give her many different classes to choose from. This will dictate how quickly we need to bring on new partners and it will dictate the design of our application. We want to make sure the assumption is true, so let’s turn this into a hypothesis that we can test given what’s important for our business: 

1. Desired Measurable Outcome: We want Melanie to love trying new exercises so much that she will purchase at least one class a week. That will give us enough revenue based on our projected number of customers.

2. Clearly Stated Assumption: Choice is the primary driver of purchase.

3. Specific, Repeatable Action: We will display different classes every week to keep her interested and engaged. 

This creates a hypothesis we can test:

If…we offer different classes per week to choose from

Then…we’ll get at least one purchase

Because…choice is the primary driver of purchase

After developing this hypothesis, we created three different prototypes on paper to test the different ways that the Melanie persona could choose classes and our hypothesis was validated. Remember, your assumption is always derived from something you don’t know and your hypothesis is based on your belief that a specific action will deliver the outcome your business is looking for. We told you to start with the measurable, desired outcome. When you start with what matters most for the business, whether that’s retention, or growth. Perhaps it’s revenue. Home in on the metric you most want to impact.

Like any practice, getting results requires constant feeding and nurturing. Starting to build a hypothesis-driven organization is going to be ugly and painful at the beginning. At first, you won’t get hypotheses that are elegantly formed and perfectly clear. A lot of them will be quite confusing and badly written and that’s okay. Pretty soon you’ll find yourself in a hypothesis-driven culture, with a team that’s always focusing on the riskiest assumptions, ready to make the biggest business impact.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

In this excerpt we change the way you think about the formulation of hypotheses to expedite your product creation process. Where we used to think of hypotheses as scientific fodder, our book transforms the definition and formulation of hypotheses into something we can use in our day-to-day product efforts; proving and disproving our assumptions so we can make quick product decisions and continue our forward momentum. Check it out.

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

We are constantly inspired with new product ideas—whether that’s through customer observations, the competition, or an “aha!” moment in the shower. Every idea has the potential to be formed into a hypothesis. The way to ensure you have a strong hypothesis, one worthy of testing, is by reviewing that they conform to these six characteristics:

Logical

This seems obvious, but think about the number of times someone has a good idea on the team. Good ideas are a dime a dozen, sadly. We’ve seen multiple teams become overwhelmed with new ideas entering the system because they see a competitor launch a new feature, or because an investor or senior leader gets inspired by the latest shiny object. Being logical means that there is clear, sound reasoning connected to the hypothesis. The idea doesn’t come from left field; you can point to evidence to suggest the outcome will be promising.

Testable

Making sure a hypothesis is testable is one of the hardest aspects of generating a great hypothesis. Often, teams feel like they need to fully build and launch their product to get actionable data so they forgo hypothesis testing altogether. While your results may not be statistically significant, think about how you might, with minimal resources, prove that you’re heading in the right direction. With practice, writing a testable hypothesis becomes easier—teams get very creative and quickly adapt to creating small tests with minimal resources.

Precise

How you put together a hypothesis counts. Using deliberate words that indicate a specific outcome is important. Otherwise, any given outcome can be seen as either confirming or falsifying. Being precise means being crystal clear on what you’re testing and why, and documenting the rationale for what it means to run the experiment, what resources you’ll need to experiment, how long it will take, and when you’ll know the results.

About Something Measurable

You need to understand which numbers matter before you do the research. If your hypothesis is that more visitors will see your webpage when you make a certain change, then you need to know exactly how many more must visit for the change to be meaningful, and thus, for the hypothesis to be confirmed. An increase of 1% may mean nothing to one company, and it may mean millions in incremental revenue to another. Understanding what measures are important gives you a good indication of whether the experiment or test should even occur. If the results can’t confirm or falsify your hypothesis, why do the research? This is a hard characteristic to pin down, but it’s critical to ask both if you know what the measurement is, and whether the measurement is meaningful.

Has an Expected Outcome

We want you to be able to explain with a logical, clear reason what outcome you expect. The line gets tricky here—if you already know the outcome, then go get the data to prove how you already know this. Why spend time testing things you already know? We see teams share hypotheses with us all the time about things they already know. They do this because it’s comforting to be proven right. On the other extreme—if you don’t know what outcome to expect, then how will you plan the precise experiment that could achieve that outcome and how could you know what to measure? Make sure your hypothesis specifies an outcome and that the outcome will address your hypothesis.

Falsifiable

The last of the characteristics is making sure that you can invalidate your hypothesis. The way to think about this is to make sure you don’t set your research up in such a way that the results are subjective, or that you’re not capturing the right data to be able to have a clear result.

These six characteristics are intended to help you coach your product managers. Instead of just providing feedback on a hypothesis (or rejecting it outright), point to one or more of the guidelines and discuss how their hypothesis may miss the mark. It’s a teaching moment and a much more productive conversation at the same time.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

As product leaders, the number one issue we see is with the concept of uncovering needs. We all have a tendency to proceed straight to features or solutions because as product leaders, we are problem solvers. But we’re here to ask you to please refrain from this tendency. Instead, pause and take time to articulate a need before jumping to solutions.

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

Earlier in our work, we worked on developing a fitness app and created the persona (a persona is a user archetype created based on your research that represents how someone might use your service, product, site, or brand) Melanie who “won’t travel more than 2 to 3 miles from work or home to work out at a studio.” That’s the need. We could have said, “We need our app to show only fitness classes or studios within 3 miles of the user’s location in the search results.” Which is a possible solution for the need. Sort of. But it shortchanges the wide-sweeping impact of the need we identified.

Instead, if we focus on Melanie’s need, we learn that she needs classes that are close to her home or work. Focusing on her need forced us to change our studio recruiting strategy in the target county to ensure a critical mass of fun fitness classes where the persona (Melanie) lived. It narrowed our studio lead-generation efforts to specific boroughs in the county. Even more specifically, it prioritized our studio recruitment efforts within each borough. If instead we had merely worked to narrow our search results by default, the search results might never have revealed enough classes. We would have had great search tech, but not enough classes in the results to drive usage.

Let’s take it one step further. What if the root cause behind the persona’s need for a 2 to 3-mile limit on distance was that the average traffic patterns in the county meant that a 2 to 3-mile distance equated to a 20 to 30-minute commute during the 5:30-6:30 p.m. rush hour time, a popular exercise time for the Melanie population. And that the 20 to 30-minute commute made it almost impossible to take classes during that hour, unless Melanie left work early. Those search result filters don’t look so great anymore, do they?

The point is, you must explore different ways to address the persona’s need and its root causes before presuming a solution. If you document and communicate needs as features, you’ll defeat yourself before even getting out of the starting gate.

Needs Aren’t Benefits

This mistake is very similar to translating needs directly into solutions. Before we jump into the feeling or benefit the persona wants to achieve, we must look without bias at the insight or need. Don’t get us wrong—the benefit helps you understand what the persona is trying to achieve, but the underlying reason for not being able to achieve that is what facilitates focus and enables action. Focus on the underlying insight or root cause of what you are observing or hearing before jumping to a solution or end benefit.

Why Individualized Needs Are Important

How do you know what to work on first for any given problem–persona combination? Can you and your team agree on a path and stick to it without overturning decisions later? Defining the Problem Statement and the Persona is your north star. That’s your starting point. The prioritized

set of needs corresponding to a specific problem–persona combination gives you the path to a solution that delights the customer, and provides the guardrails for the areas to focus on or avoid when solving for that problem and that persona. It ensures your focus for ideation and feature tradeoffs, whether it be your first version or your next product release.

Needs Enable Confidence in Early Feature Tradeoffs

Doing the Groundwork to identify and prioritize needs surrounding a specific problem for a given persona allows you to quickly say no to certain features or exploration. You can easily justify to leadership why you didn’t pursue a particular feature area with a statement like, “Melanie’s primary needs are X and Y, which is why we focused more on these features and tabled these other features for now.” It keeps the tradeoff discussion out of “opinion land” and solely in “customer-data land.”

Needs Enable Clear Prioritization of Your Time

When you know and agree upon the prioritized set of needs for your persona(s) your team has the permission to focus their time on what matters most. Providing focused ideation time, testing, and iteration around the most important aspects of the solution. Which said a different way, you aren’t spending time on random, broadly scoped aspects of the solution that are less likely to drive delight. It’s the other side of the “saying no” coin.

Needs Enable Faster Time to Market

Because you can confidently make tradeoffs early and test and iterate on only what’s most important to your persona(s) you’re able to avoid the delays that come from endless feature debate, overturned decisions, and designing or testing things that don’t impact the delight of your primary persona(s). This dramatically reduces your cycle times and your overall release cycle.

Needs Minimize and Potentially Eliminates Costly Rework

Finding that you didn’t hit the mark on the most important needs of your persona after you’ve built and released your shiny new experience is painful. Doing all the Groundwork reduces the pain of rework after you release. We’ve all spent a lot of sleepless nights agonizing over something learned soon after release that seemed so obvious and could have been identified early on had we just done the needs investigation and prioritization.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

This excerpt is great for any product leader or product manager trying to make more customer-driven decisions that won’t be overturned at the next meeting. One artifact that helps in this plight is the persona. Don’t roll your eyes! There are ways to develop effective personas that drive action for your teams and not just collect dust on a shelf. This excerpt from our book introduces some pitfalls that teams fall into in the development and use of personas. The full book expands on this and more!

The following has been excerpted from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

We once walked into our client’s building (name not mentioned to protect the innocent) and as part of the kickoff for the project, we asked for any documentation they had on their target customer. “You mean personas?” they asked. Yes! Exactly! 

They tapped out a message on Slack and minutes later, the UX designer walked into the conference room and placed three laminated, full color, 20” x 30” flip charts on the table. Each had four pages of detail, including pictures and text. Our eyes widened for just a second. As we started to thumb through the beautifully produced flip charts, we started asking questions. 

PR: How are these used?

Client: We use them when we design or redesign areas of the UX.

PR: Does the extended development team have copies of these? 

Client: No. They don’t need them.

PR: When was the last time you used them? 

Client: About three months ago, when we redesigned the onboarding experience.

PR: How were these developed? 

Client: We hired a design firm to research and produce these for us.

They had big, beautiful, professionally created personas they could hang on the wall, and could even spill food and water on without issue! And the research team used them. So, what’s the problem here? There were a few things:

It’s Not a Contest to Write the Longest, Most Detailed Persona

Don’t be fooled. Less is more here. You want the entire organization to know the personas, use them, and refer to them in all aspects of the product planning and creation process. They need to be simple, easily communicated, and constantly referenced.

It’s Not a Broad Persona

Too often we see wide swaths of the population depicted as the target market because they all experience the problem we’re solving. Hence, we create a broadly scoped persona. That may include solving it for someone who has the problem but doesn’t feel enough pain to act on that problem. This is a huge pitfall to avoid. Your target personas are only those willing to take the action you want them to in exchange for solving their problem; be it open their wallet, donate their time, respond to your communication, and so on.

One question we recommend asking during persona-related research is, “What would you be willing to pay to have this problem solved?” or “What would it take for you to open your wallet to pay for this solution concept we’re showing you?” or “What would you expect to pay for a solution like this?” Choose your own words to help you understand whether or not the research participant would be willing to take the action you want them to take. 

This is not meant to be a pricing discussion. We don’t recommend interviews for pricing research. To be clear, you should be focusing on people who have expressed a willingness to pay, donate, or act to have their problem solved and not those that show a mere interest in solving the problem. Your persona will become clearer as you understand who is willing to pay and who isn’t.

It’s Not About Outsourcing

Taking ownership of your customer is your job. This is the Groundwork you and your team must do with your own hands. Interacting with customers, discussing what you learned with the team, and coming to a shared vision on your target persona is a requirement for creating products that customers love. Don’t get us wrong—we do outsource research, but there is a time and place for outsourcing. For this aspect of the Groundwork, you need to learn from your customers firsthand.

It’s Not A Laundry List of Demographics

Our client didn’t make this mistake—they did a great job of deeply understanding the archetype and bringing each of these personas to life. But we frequently see personas represented as a list of demographics and a couple of attitudes, rendering the personas one dimensional and not actionable. Demographics are good for marketing in terms of buying direct mail lists, filtering within social media campaigns, and calculating available market sizes. But they are bad for making product and design decisions. You need to understand attitudes, behaviors, goals, a day-in-the-life, and similar information.

It Isn’t A Job Description

Many B2B personas we see describe a job and the daily tasks within that job. A list of job responsibilities is very helpful when you’re trying to understand where your problem space fits into the world of that persona and when you’re identifying relevant needs that must be addressed to solve the problem well. However, just knowing a person’s daily job tasks tells you nothing about who the person is or how you should build an experience that delights them. So, in other words, a job description is helpful in describing the “what” you’re going to do, but it doesn’t give you any guidance on “how” you’re going to do it. There are many ways to design a feature depending on the traits of your user. The feature addresses the task at hand but the design approach (the aesthetic, placement of buttons, vernacular used, types and number of steps to complete the task, etc.) will vary widely depending on who you are building that feature for. Avoid just focusing on what could turn into features (job tasks and responsibilities) and focus more on the inputs to your design approach (this person’s aspirations and how they go about their daily life).

It Isn’t “One-And-Done”

Personas are always evolving. Most of the time, you start with hypotheses about who your target user is. You’re never right the first time. For example, you may assume your persona is focused on accuracy given that they are an accountant and spend a lot of time playing the role of “accuracy police” with their staff. But as you conduct more research to investigate their needs you find that, yes, accuracy is important, but they actually view themselves as a coach that helps their staff build good data hygiene. 

Think about how differently you might design an accounting software experience for someone who views themselves as a coach to help others with their accuracy checking instead of someone who views themselves as the “accuracy police.” The former might have the product team prioritizing data reconciliation functionality for the staff roles, while the latter might prioritize the ability to check their staff’s work. It doesn’t mean you can’t do both, but it certainly would dictate your prioritization of the two areas of functionality.

As you conduct more research you will learn more about your target customer, proving or disproving your hypotheses and refining the persona. Without this refinement, personas get shelved and become out of touch with reality.

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

For you product leaders that are struggling to make the tough tradeoffs. Our book’s definition of the Convergent Problem Statement can help. This excerpt references some strategies in establishing just that with your team in order to make product decisions much more efficient and durable.

The following excerpt is from Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin. 

The Convergent Problem Statement is just as useful for new products as it is to prioritize features for existing products. We love starting ideation with a couple of the most compelling problem statements, helping us to explore and ultimately prioritize which customer problem our business is best positioned to address. 

As a reminder, a convergent problem statement clearly describes the most relevant difficulty the customer is dealing with and is stated with no attempt to address possible solutions.

For product leaders, the best way to support your team is to be deeply involved and invested at this early stage. When you help your product manager (PM) work towards a Convergent Problem Statement, you set the Groundwork for a successful product. Here are some strategies to working with your PMs: 

• Insist that every “idea” is framed as a problem statement. In our work, we’ve even created mini templates and asked anyone in the company to share product ideas as long as they write the ideas in the form of a problem and not a solution. This helps cut down the noise of new product ideas since there is the small hurdle of entering it as a well-formed problem statement. This practice helps our team source new ideas, and highlights people in the organization who are passionate about solving customer problems.
• Share the iterations that helped you converge to the chosen problem. You want to show by example that no one gets it right the first time. By showcasing examples, you provide a roadmap for how you want your product team to think. Many problem statements start with a lot of guesses, and then you refine them through learning. Show that journey for your teams to emulate.
• Highlight “failures” or problem statements that ended up abandoned because you proved there wasn’t actually a problem! We’ve all been captivated by new product ideas or solutions that we thought were so obvious. When we do the work we uncover that customers had a simple workaround, or felt lukewarm toward the idea, or discovered the problem wasn’t important enough to want to pay for a solution. We’ve shared when a customer’s “good-enough” solution was sufficient or the pain wasn’t high enough for them to choose an alternative. By highlighting examples, you demonstrate the rigor that brings a product or feature onto the roadmap. You’ll see all the teams you work with gain confidence knowing that customers are waiting for their solution.
• Never assign development resources unless you are satisfied that there is a genuine Convergent Problem Statement. This can feel painful when there are engineers available and both you and your product manager feel the urgency to create work. You have to stay strong! You’ll avoid much pain and suffering (which can manifest as bad customer reviews, rework, and unhappy teams).

 

If you like what you see, there’s more where that came from. Pick up Groundwork: Get Better at Making Better Products by Vidya Dinamani and Heather Samarin from Amazon.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies, small and enterprise level, in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences. We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com