3 Steps to Identifying Where Hypothesis Testing is Critical

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

6 Elements of a Strong Hypothesis

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:


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.


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.


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.


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

Why Your Product Should Be Needs First, Features Last

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

A 6-Part Formula for Developing a Customer Problem

Okay product leaders, this excerpt sheds some light on how to create a problem statement that works to focus the team and allow for you to say ‘no’ confidently. Take a look.

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

Let’s examine what goes into a Convergent Problem Statement. 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. We want to clearly define the problem in detail so that anyone reading the problem statement can immediately understand the situation. Every problem statement should address the following six questions.

1. Who Does It Impact?

You need to be able to imagine the person impacted by the problem. Start by defining a real human being—someone you can relate to. Developing a sense of the person who has the problem immediately creates a sense of empathy. This empathy allows you to better understand the problem. Don’t focus on demographics; think about a specific person in a particular role. You don’t need to name them, but you do want a sense of who they are, where they work, and what their day-to-day life might look like.

2. What Are They Trying to Do?

You want to understand the context in which the person is operating. Here you’ll think in more depth about where they live, work, or play. Their surroundings matter. You need to know what they have access to, what their environment looks like, and what options are available for them. You start to build a picture of what they have access to, and the workarounds or options they may consider to naturally approach the problem.

3. How Do They Want to Feel?

We love this question. Yes, it’s touchy-feely, but it goes to the core of why someone will care about the problem being solved. And for all you super-analytical types, this will be a cornerstone as you think about marketing. Understanding the emotional toll of the problem will help you sell the benefits of using your product. Every problem in your life leads to an emotion.

When the person you envision experiences the problem at hand, do they feel annoyed? Grumpy? Frustrated? Angry? Exhausted? 

This is one of the hardest questions to answer, so keep exploring different adjectives until you find the one that resonates. When you land on the right emotion, it will feel like an “aha!” moment. Understanding how your customer feels can reveal whether the problem is a serious or a trivial one. Asking these emotion questions help you determine the list of features needed to solve the problem, develop the solution, and price it. But let’s not jump ahead of ourselves; there’s still more to learn about the problem.

4. What’s Getting in the Way of Just Addressing the Problem?

When customers have problems, they’ve usually tried to address them in some way if it’s important enough. Have they tried alternative solutions? Did anything partially work? Have they created workarounds, whether that’s through supplementary software or manual steps? Have they tried to reduce the impact of part of the problem? What are the biggest barriers to resolving their problem? Is it lack of awareness? Budget? Time? This question asks you to both ask direct questions, and also to closely observe behavior and actions.

5. When Does This Problem Occur?

This question is about timing. Is this a recurring problem? Is it a daily or a weekly problem? Does it only occur at the end of a fiscal quarter? Or does it occur once, but when it occurs, is it extremely painful? Understanding the frequency of the problem gives you a sense of the scale and size of the problem. This question pushes innovative thinking; understanding what’s happening for the customer at different points of time allows us to consider alternatives.

6. Why Does This Problem Exist?

As you complete the problem statement, start to develop a hypothesis about why this particular problem exists for your customer. What gets in the way of just going about their day and avoiding this problem? Are there any alternative solutions or products that are just not viable, or is there no solution and they are creating a set of workarounds? Try not to go straight to willingness to pay for a solution as the answer, after all, people will pay a lot to solve an important problem. Instead, consider other factors that might be causing this problem. 

Remember, it’s for the particular person that you imagined in the first question (who does the problem impact?). Don’t generalize across a population to determine why the problem exists.

The answers to these six core questions paint a picture of your customer and their problem.


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

6 Common Mistakes to Avoid with Customer Personas

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

4 Things Every Product Manager Needs to Think About Before Development

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

Virtual conferences create delight

Like you, we’ve were disappointed and sad to see all the in-person conferences cancel one after another. In the early days of the pandemic, some brave conference organizers decided to switch to virtual experiences , but these first few experiments were mostly pretty painful. Trying to recreate the excitement of an in-person experience was so daunting, most didn’t even try. We watched webinars, and gave presentations had no interaction with anyone else other than through a chat box, or moderated through a host. Luckily, there’s been a lot of experimenting in the last six months, and now we’re starting to get delightful online experiences. In the last month, we’ve attended three amazing virtual conferences which have exceeded expectations. They’ve transformed expectations of conferences and they created delight. We want to share three examples of these experiences with you because they’ve re imagined their offering and we hope it inspires you to think differently about your product and customer experience.

  1. Personal Connection. Networking can be hard at in-person conferences. They can be awkward affairs where it’s hard to make a meaningful connection. I have tons of business cards from various conferences, but no memories of their owners. In the Product Leader Summit conference last week, the organizers offered up three virtual networking sessions starting a week before the conference. There are multiple networking apps, but the better experience was that there were multiple chances to connect in six minute chunks, which is enough to have a real conversation when it’s just 2 people. You get to sample a personality, make a connection and then decide if you want to continue the discussion. There are multiple apps that offer networking, but consider the experience. The networking portion was received so well, there were requests to continue these post-conference.
  2. Shared Experience. It’s hard to create a shared physical experience when we’re all sitting at our own desks. However, the Women’s Venture Summit, offered a happy hour get-together in between their 2 day conference. This event asked the audience to purchase a set of ingredients a week prior to the conference (with lots of reminders so that we were ready). The maker of the featured cocktail, Emily Josenhans of Domain Sante, made a new beverage (crafted by her team) online. She took us all step-by-step through the process, and we created a cocktail (or mocktail) together. I’ve been to many happy hour events online, but creating something together made the experience much more delightful.
  3. Insights & Learning. Zoom breakouts are a good way to break up any large group and have people able to talk to each other. In two conferences, rather than a random distribution, we were told why we were put together in the groups. This information about who would be in the room with you was shared a few days in advance, so we could look up (linedin stalk) the people we would be meeting with. This act of forethought made the breakout room immediately more active, because there was a sense of knowing the other attendees were. They also helped much better attendance, knowing that a group was expecting you to show up. There were better conversations because we felt accountable to prepare to share thoughts with a team we’d never even met. We all use breakout rooms, but consider designing an experience instead of hoping for the best, so that attendees have a significantly better chance of learning from each other.

Each of these examples elevated and improved the conference experience because the conference organizers deeply thought about the attendee (customer) needs. They knew what in-person conferences promised, and they worked with existing technology (not developing a single new feature or product) to not just improve, but create delight. How can you go back to your core customer needs and given the new way in which we all live and work, deliver an experience that delights?

An Outline for an Effective Customer Learning Review

Well, year end is around the corner. We just talked about strategy, but what about the nooks and crannies of strategy? What we mean is one of the most critical inputs of strategy. Customer Insight!

Many product leaders fail at providing a well rounded review of customer learning. They move straight to the actions and implications to stakeholder (e.g. UX, development, marketing, operations) without the insights that drove those proposed actions. We see product managers cherry pick the data they believe supports the decisions they’re proposing. Regardless of whether the decision is right and how true your intentions are, cherry-picking breeds skepticism and a lack of trust from those who may have other data that leads them to favor a different decision. The whole discussion gets derailed and your reputation as a customer advocate and unbiased business leader begins to tarnish.

We recommend, after every major research study, you circle back to your cross functional partners (dev, ops, marketing, etc.) to discuss your customer learning. And we have a good outline for those reviews that we offer to our clients’ product managers that works every time. What do we mean when we say it works? We mean that durable decisions can be made, teams can commit to executing against those decisions, and trust in you as an unbiased leader is maintained.

Here’s the outline we recommend for most research studies:

Customer Research Review Outline

  1. Hypotheses: What were the goals of the research? What did you want to learn and how did you intend on using the data?
  2. Profiles targeted and research logistics: Provide context for who you talked to, how you conducted this research, and why it’s relevant. How many did you talk to (for qualitative research) or survey (for quantitative research.)
  3. Resulting themes & insights: These are the big Aha’s of the research. They should represent what you learned (factual observations) and how it addresses (proves or disproves) any given hypothesis (your conclusions). These shouldn’t be one-offs or interesting tidbits. That comes next.
    • For qualitative studies with low sample sizes (we believe in scrappy research, so many of our customer learning reviews are summaries of interviews with a small sample – five to seven – of participants,) report on anything mentioned across participants more than two times.
    • For bigger samples or quantitative research, these are important, statistically valid themes in the data.
    • Include any additional important themes you uncover that might not directly address your hypotheses. Just try and focus on the goals before bringing these in.
    • Bring all this to life by using the customers’ voice. Use actual quotes, pictures, or even a video from the sessions. Hearing directly from customers amps up your presentation substantially.
  4. Interesting tidbits: You can include anything mentioned that wasn’t a theme but could be a thread to tug on later through additional research. This might be a surprise finding, or a potentially new problem or segment you might explore. Tidbits don’t have to yield a conclusion or action, but they may be worth exploring later, and therefore, you want to highlight the information.
  5. Recommended actions: This is the most common thing missed if and when product managers present research findings. Recommended actions help the team with the “So now what?” question. Do we stop the dev effort? Do we pivot our design direction? Do we add that feature? Do we have to think differently about our persona? What does all this mean in terms of what I do tomorrow? Tell your audience explicitly what you plan to do based on what you (and they) just learned. If you don’t know, throw a little design thinking exercise in there to collaborate on the next steps!

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 kickass customer experiences.    We have a passion 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.

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

And stay tuned for our new book.  Sign up for updates on our new book “Groundwork. Get Better at Making Better Products”

10 Tips to move Strategy Sessions Online

We’ve written this article to help you plan a focused and effective strategy session when you’re all online/virtual. This is targeted towards product strategy sessions, but these 10 tips will work as effectively for bigger company strategy sessions. Just a note – moving your session online takes work. At the very minimum you need 3 weeks of pre-planning. Start soon!

  1. Design for outcomes. Remember a strategy is the plan by which you achieve your company/product objectives. A strategy meeting is the means by which you collectively create the plan on which you’ll execute. This might seem obvious – but it’s easy to lose sight of the reason you’re bringing people together. We’ve been in lots of in-person strategy offsites that end up more as information sharing sessions – or team bonding, or an excuse to talk about loads of new ideas (shiny new object syndrome!).  Then all the decisions get made at the post-offsite strategy session. Virtual strategy sessions need to be designed carefully. Start by getting really clear on what you want at the end of the virtual sessions and what information is needed to achieve the results you’re looking for.  Are you looking to refresh your strategy entirely, or are you looking to validate existing strategy? Has your business set new growth targets because of the pandemic, do they have a new set of objectives for the coming year? What factors will you have to consider – COVID impact, competitor analysis, market research, customer learnings, sales & finance updates, technology needs – what has changed and what is relevant?  Now write down what success looks like – share them with your peers so that you’re on the same page. Here’s an example: We need to update 2 out of 4 of our existing strategies in order to meet the new growth target (list the two). A successful strategy session means that we have produced a draft set of product strategies that are aligned to the company objectives and strategy, and each team is positioned to create a set of initiatives that are driven by strategy.
Pin by Amanda Dykman on Ahhh...The Work Life | Work humor, Work ...
  1. Break it up: We’ve all been on all-day offsites where we immerse ourselves in strategy and so the urge to replicate the process is strong. But you just can’t possibly do an all day strategy online – it’s painful even thinking about sitting in front of your screen for that long for one meeting! We’ve learned that 2 hours is the ideal time to have the team fully engaged, energized and effective. We’ve tried longer periods and it’s hard to keep everyone focused. 1 hour isn’t quite enough – people are getting warmed up and you’ll find yourself going long anyway. Some teams have insisted that we work in 4 hour sessions – but we see fatigue set in, then we take longer and longer breaks – it just doesn’t work. We recommend a series of 2-hour sessions spread over a week. With the right planning, this set of sessions can be even more effective than an in-person offsite.
  1. Set mandatory pre-workTo make the most of 2-hours together, you need to set pre-work. As you determine success outcomes – you’ll naturally uncover the most relevant topic areas (competitor analysis, market/economy, customer success, etc.). Two-three pages of pre-reading for each area is recommended. Summarize each of main points:  clearly list market & customer insights that are most critical to the discussion, articulate each of the major problems that need to be addressed. Write these down  in a paragraph or two, providing key data and backup links for anyone wanting to dive deeper means that everyone coming to the sessions is prepared. You can send all the pre-work together a week before your session, or set your sessions to be 3 hours, with the 3rd hour individual time for the team member to do the pre-work each day. This isn’t easy – but it’s invaluable for having great sessions. And we recommend asking people not to attend if they haven’t done the pre-work, don’t let your sessions devolve into opinion-sharing. Keep discussions focused on facts/data.
  1. Assign Champions. Share the workload and assign champion to each of the major sections of work. This is a great opportunity to highlight your team, or to even ask important peers at your strategy sessions to lead. When you engage others in leading the pre-work research, or summarizing the data points – you take the burden off being the sole facilitator, and all the research coming from one voice. You want everyone at these sessions to feel ownership over the strategy that’s developed, and one of the best ways we’ve seen to achieve this, is by starting with ownership right from the start.
How to Lead Better Virtual Meetings - Duarte
  1. Write down assumptions. When doing the pre-reading, have the team write down their assumptions. This way, each team member is coming in prepared with a set of notes that lend themselves to a discussion. The pre-reading is not just for information, but to help form product strategies (remember #1, outcomes!). The reason we recommend this approach is that it helps provide the rationale for the opinion.  It’s much easier to invalidate a stated assumption, rather than argue opinions. We really don’t like opinion-based discussions if that isn’t already obvious. When the team can’t readily invalidate an assumption – this can easily be turned into a hypothesis that can be tested after the meeting. We know exactly what information we need to help us make sense of the data.
  1. Address the elephants. Don’t bury bad news in the pre-reading or avoid it altogether. Some of the teams we’re working with are losing their funding, others have seen their customers disappear or put purchase decisions on an indefinite hold. This is critical information, and it’s not business-as-usual. You want the most out of these strategy sessions – you want your teams to armed with all the data. The impact of the elephants are pretty significant in terms of how the company will respond – perhaps the growth targets have doubled, or the retention goal has increased significantly. Make sure the pre-reading provides the “why” and the context – and don’t avoid those big, hard problems.
3 lessons learned when developing a new product with the Minimum ...
  1. Standalone Ideation. It’s really easy for each of these 2-hr strategy sessions to devolve into ideation sessions. Once people have their pre-reading done, and they understand what the business is trying to achieve – they’ll want to solve problems – it’s natural. We’re all full of product ideas, and asking people not to share them can be painful (and derailing). But you don’t want to continually talk solutions before you get a full understanding of all the areas that need to be reviewed. We suggest having a shared whiteboard to capture all the ideas generated. Don’t have this as a shared screen, you don’t want it visible and distracting – you just want a place where people know that they can add their ideas/solutions. Once you’ve finished the information sessions, you can move into ideation for product strategies. This is towards the end, and a 2-hr focused session on strategy ideation is ideal. Having your list of whiteboard ideas is a perfect input for this. Your team can self-select which ideas move forward, and which go away now that they are fully armed with all the background.
  1. Small Discussions. We design our strategy sessions to be about 5 minutes together as a large team, then 15–20 minute sessions with a small team. By small team, we mean about 3–4 people, a group where everyone has a voice. We move in and out of this format — so that we’re constantly regrouping, sharing updates, and then going back into real discussions. Consider if you want random groups so that different people are constantly reviewing data. This is good when you have a close working team, and the groupings are less important. Perhaps you want to deliberately create cross-functional breakouts if you have invited others in the company — you’ll want to design each small groups to have a voice from all the functions that are represented. This is an important part of pre-planning, looking closely at putting the right people together.
  2. Document Collaboration is a must. Zoom, or teams, or whatever video software you use is insufficient. You want to be virtually around a working board where the pre-reading is loaded, the assumptions are listed – everyone can see and have access to the documents and be able to write their own thoughts/comments. We have been using the in-built notepad on zoom, and then Mural to share all documents. We pre-build our boards with stickies – color-coding for teams, and sometimes individuals – so that we can make sense of all the notes at the end of the session. Avoid a facilitator writing down other people’s ideas – it’s nowhere near as effective as enabling everyone to have control over exactly what and how much they contribute.
No! No! Not Another PowerPoint! (BoomerBlix)
  1. Lose the PowerPoints. Hopefully this goes without saying given the first 8 tips – we want the strategy sessions to be all about working together, discussions and making decisions. Feel free to create PowerPoints for pre-reading if that fits with your company culture. But by no means spend any time (not even 1 minute) sharing a PowerPoint deck. You’ll set the tone and expectation for this session if you avoid PowerPoints altogether. Let’s be clear – we’re still asking you to make sure that everyone understands the pre-reading. You should still start each session by recapping or highlighting the relevant facts, check in for understanding and questions and then jump into the assumptions that people have written down. Work through the data in a structured way. We just don’t want you reading slides!
Zoom party tips: Virtual hangout ideas for a fun night in - Los ...

Bonus tip!: Don’t lose the happy hour. Last, consider how you can celebrate together at the end of the strategy session. Maybe it’s a separate hour after every session is complete – but it’s important to acknowledge the end of this hard work. Here are some ideas that we’ve experienced or seen work. Send everyone a bottle of wine, or their favorite beverage a few days in advance, so you can open it all together at the end of the session. It’s always fun getting a surprise in the mail! I took part in a chocolate tasting by an expert a few weeks ago – I was sent a package of 4 bars (yes, it was hard not opening those) and couldn’t wait for the event. It turned out to be a really fun experience, as we all opened packets and tasted together while the expert shared the history and taste notes of each bar. A month earlier, I was part of a sommelier experience, and the prep for that was to bring in the bottle of wine that you’d always been saving for a special occasion – so the only company expense was providing the expert. Hopefully these ideas get your creative juices flowing – whatever you do, mark the end of the session with something fun and a way to connect and have a shared experience.

Agile is GREAT, but…

Agile is great, but…

Agile is awesome. Nearly every Product Manager we know would agree. But I bet you’d be surprised by how many conversations we have with product leaders around their questions, issues and sometimes not-so-stellar experience with agile development. Questions & comments like:

  • Our product managers/owners feel constantly overwhelmed working day-day with dev, we have no time for innovation!
  • Anyone else have confusion over roles within their agile teams, or is it just us?
  • How are others dealing with technical debt, our seems to just keep growing…
  • Do you need to have both product managers and product owners?
  • We can’t expect our product owners to also be strategic…can we?

Agile is so clear about roles, and ceremonies. Backlogs are groomed continuously to focus on the highest priority. Customer Value is built right into the manifesto. So, why are there so many “we love agile, but…” conversations in the product management community. What’s going wrong? We have a hypothesis on why this is happening, and a proposal for a universal fix across all agile teams. Let’s start with three assumptions that we have about how we believe products should be built.

  1. Before you build…You know what is important to customers. There’s a loaded sentence. We built an entire business helping companies get this right. Anyone can create epics and sets of user stories — that’s easy. That’s how exploding backlogs happen. Because it’s just so easy to create work, and agile is a well-oiled machine designed to keep churning out work in tidy increments. But, as we all know, outcomes aren’t equal to effort. And meaningful business outcomes are those that prove we’re providing value — because customers buy and continue to invest in the products we deliver. All that comes from deeply understanding your customer.
  2. Before you build…You can define the customer problem. That doesn’t mean being able to describe all the incredible features you’re building. It does mean being able to state the customer problem that exists, independent of your product ever being launched in the world. That means, there are lots of ways to potentially solve the problem, but you (team, company), are uniquely positioned to deliver a solution that will win in the market. And btw, the problem should be a big enough pain that the customer is willing to pay to make it go away. When you can do this, you know you’ve got an important problem to solve.
  3. Before you build…You have a vision and a roadmap. A roadmap is not a rolling collection of features — it’s a clear, well-thought out, logical and prioritized map to achieve a vision. Having a vision is what allows you to make tough trade-off decisions, and it’s what keeps the team (and you) energized and motivated to make it happen through all the ups & downs of development. Having a vision starts with #1 & #2 above — knowing what’s important to the customer and what problem you’re solving.

If you buy into these assumptions — then let’s talk about how you can leverage them to make a big impact on how well agile can work for you. This is based on years of experience working as a product leader with with dozens of agile teams, and from our coaching practice improving the ways that product managers and product owners can succeed working within agile development.

You have to know where you’re going. Remember the bad old days of waterfall development? If you don’t, lucky you! For those of you who shuddered when we asked the question — you had flashbacks of writing massive requirements documents. But, the one (and maybe only) good thing was that it forced you to think about where you were going. You had to think about the big picture before you could break it down to endless requirements and (depressingly) writing down every possible exception. We’re not suggesting for a second we go back to the dark ages. However, what we’ve missed in our head-first dive into agile is providing the team with the big picture in a way that’s meaningful. That doesn’t mean one flashy PowerPoint slide of a vision, or some high-level product mockups which makes your CEO happy. We’re talking about providing a real schematic that offers a picture of where you’re going, and enough details that allow the teams working with you to ask great questions, offer alternatives and help improve the overall solution.

Let’s say you were giving the job of building a house, your first step probably wouldn’t have been to assemble a building crew, and say to the foreperson — we’re going to get started and build a room at a time. Let’s see where end up! Before you had a team start to pour concrete, or put up framing, you would have worked with an architect to create a plan. The inputs to that plan are customer needs. Imagine a home for a young couple, mobile, working from home, wants amenities/access such as pool/gym…and then think about a family with 4 kids, one member is in a wheel-chair, they entertain a lot, generally home-bodies. Very different needs, very different home. Your understanding of how the home would be used, the people who live inside, what they would do within their home — all of these are critical elements in understanding the type of building we’d create. We don’t expect a building crew to start building without a plan — and the opportunity to ask questions, and maybe suggest some changes that would make it cheaper to build, or offer additional value elements for the same price. Because they understand what you’re asking them to build — they can have a voice.

The same is true for a product — we need a picture of our customer, what she cares about, her habits and attitudes — and through understanding this, we enable our teams to imagine a real person that we’re building our product for. A product manager’s job is to provide this picture. Agile wants you to know these things -it really does. It just doesn’t give you any time to make it happen. If you forgive agile for not building in a ceremony just for product management, then it changes the way you will look at your development cycle. The way to coach teams to provide this critical information is to develop and share a Product Scope. A Product Scope gives the schematic, the plan for what you’re planning to build, it provides a picture to the team so they can imagine it. They can then connect with you on the plumbing, the electrics, they may even suggest shifting rooms around, or describing a completely different approach which you never imagined. This will happen because you have everyone on the same page, then…you can begin Sprint 0, start planning and happily create epics and write user stories. You all know where you’re going.

Having a Product Scope will change your experience with Agile

We’ll talk more about how to create a Product Scope in a follow-up post and the product work needed before sprint planning. We’ll give you a hint — writing kick-ass Product Scope documents comes from deep customer understanding, which starts with setting up hypothesis, ideating, prototyping, testing — all with customers.

Before we close, just a couple of extra agile tips for kicks. Spikes are not your friend. A lot of the time, we see customer research being placed on a sprint plan as “research spikes”. A spike, technically is something that is not clear to the team, or can’t be estimated well. The whole purpose is to provide an answer or solution so that the team can get going again. Assigning points to research is meaningless — your entire product success rests on your ability to learn from your customers and build that into every sprint. That’s right — you should be learning from your customer EVERY sprint. That doesn’t mean fitting them into research spikes. btw, spikes aren’t great for the team either, it impacts velocity and timelines and all the things your scrum master cares about. Don’t use them.

Build in Time to Watch Customers. Technically this isn’t an actual way to make agile work for you, but it’s just the very best gift you can give your team. It works whatever development method you’re using. It will change the way your team work. We suggest at the very minimum once a quarter, you should provide a way for your team to spend time watching customers. It will dramatically change the customer value your team delivers.

What other agile and product management tips do you have? Share your comments and thoughts.