post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

How to build a companion product and win user trust

mission statement

Deep dive: Crafting your product vision and mission

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Sharon has been working in the tech industry for over 15 years. She started her path as a Software Developer, where she got exposed to the Product Management role which she found fascinating. 10 years ago Sharon made a career change and got her first role as a Product Manager, and never looked back.

She specializes in building B2B products, especially in early stages, getting them from incubation stage to commercialization.

Sharon Feldstein

In this guest post, <a href="https://www.linkedin.com/in/sharon-feldstein-80066053/?originalSubdomain=il">Sharon Feldstein</a>, Head of Product at Affogata, discusses the journey of creating a new product, and how we can avoid falling into the Valley of Despair, a common problem that many product managers face.
<hr />
How do you group yourself together once you reach the Valley of Despair, and I am not talking about the Monday Blues, I am talking about the moment that you, as a product leader, understand that the main assumption that you made about your product is incorrect.
But let’s take a few steps back, to the moment you decided to invest in a new Product line, a new market or a new direction for your product. It all starts from an assumption. An assumption you made after talking with the sales team about new opportunities in the market, or one that you formulated after doing some user interviews, market research or a competitive landscape analysis. Whatever the reason that got you there you always begin with an assumption.
<h2>The journey of creating a new product</h2>
As good product people, the first thing we do is start planning our validation process &#8211; How can we prove that we are doing the right thing?
We start developing our proof of concept (POC) either by mocks, a simple web/ mobile application, a landing page, or whatever method we choose, and this is the point where we start climbing “mount stupid”.
Simply put, it means that the less you are familiar with a certain domain or problem, the more likely you are to feel that “you got it all covered” (<a href="https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect">this is a cognitive bias common to us all that was researched by Kruger and Dunning)</a>
We basically still don’t know how much we don’t know, and this may lead us to a false illusion that we know how to solve the problem of our users and create a successful product.
Since we already established that we are good Product people, we will put all needed effort to learn more about the domain, the relevant personas, and try to validate our assumption.
In some cases, we will find out that our assumption was incorrect. This is where we take the steep fall to the “Valley of Despair”.
<h2>Recovering from a wrong assumption</h2>
This is what happened to me in a company I was working for. After getting positive signals from our market, and investing several weeks in potential users’ interviews, we decided to develop a new POC for a new Product Line that we wanted to launch. Our study showed a really high demand for this solution and the company allocated to us the needed resources to go for the win.
Upon the first release of our MVP, we did some ground work to see how people interact with our product. We soon found out that they didn’t understand why they needed it and thought it only complicated things for them. They didn’t like it. It took us another few rounds of “why” interviews to get to the bottom of it, and in the end, we came up with the conclusion that our initial assumption was incorrect. We captured the pain correctly, we just didn’t understand the real root cause, hence building a solution to the wrong problem.
I still remember the cold sweat and slight feeling of panic when I understood that we got it wrong. But at least now we know.
<img loading="lazy" decoding="async" class="alignnone size-full wp-image-31676" src="https://www.mindtheproduct.com/wp-content/uploads/2022/12/Screenshot-2022-11-30-at-15.52.45.png" alt="" width="481" height="374" srcset="https://www.mindtheproduct.com/wp-content/uploads/2022/12/Screenshot-2022-11-30-at-15.52.45.png 481w, https://www.mindtheproduct.com/wp-content/uploads/2022/12/Screenshot-2022-11-30-at-15.52.45-300x233.png 300w" sizes="(max-width: 481px) 100vw, 481px" />
<h2>So where do we go from here?</h2>
First, remember that the story doesn’t end in the valley of despair, but that it is one step in a long journey we take when launching a new product.
Dis-proving your assumption is also a good result. It may not be the result you yield to, but if you are going to fail it’s best to do it fast. The worst thing Product leaders and managers can do in such a scenario is deny the results and move on hoping that something will change along the way, or that things will just work out. Think of the consequences of failing in a much later stage &#8211; the money that is spent, the wasted hours of work, and the motivation of the teams involved that may be severely impacted.
What you should do is a root cause analysis to understand what was incorrect about your assumption. Here are a few examples:
<ul>
<li>Did I capture the true pain of the users?</li>
<li>Do I really understand what causes this pain? Is it the current processes, lack of information, or lack of time?</li>
<li>Do I really understand the day-to-day of my users and how my solution is going to change it? Is my product going to fit with their current processes or is it going to cause a disruption in their daily work routines?</li>
<li>Is the adoption process going to be long and tedious? Have I properly prepared for it?</li>
<li>Does my solution fit the persona? Is it too high-touch? too complex?</li>
<li>For B2B products &#8211; you need to think of the motivation of the buyer vs. the motivation of the actual end user. Sometimes they conflict with each other.</li>
<li>And finally, it may be that the packaging is not right &#8211; the business model or the pricing may be off.</li>
</ul>
Now that you understand what wasn’t working, you can gather your team and think of the needed changes or even a pivot to make it work.
This process may repeat itself a few times, as you and your team continue learning and adjusting your product as you go, but if you do it right, you won’t experience such a deep fall again, and in fact, you will start climbing the “Slope of enlightenment”. This is where you know enough about the domain and your potential users that you won’t be surprised by “unknowns” again (at least not major ones), and actually start building real solutions.
This is what we did back in the day &#8211; We examined what we learnt, and planned a new POC according to our findings. It wasn’t a smooth ride, and it required us to constantly adapt to what we found &#8211; but we were learning, and progressing and eventually were able to build a product that solves a real customer pain. We reached the Plateau of Sustainability.
The Plateau of Sustainability is where you gain enough knowledge and confidence about a specific domain and can handle whatever obstacles that may come across your path. This is where we want to be as product leaders.
<h2>Wrapping up</h2>
My main takeaway from my experience is that although we cannot possibly know everything when we start working on a new product, we have to be aware of our (human) limitations and strive to get our assumptions validated as soon as we can. Once we reach the Valley of Despair, we have to quickly bounce back, and do what we do best which is ask “why” as many times as it takes until we fully understand the issue and plan our next move according to our learning.
<h3>There&#8217;s more where that came from! Access more insights on Mind the Product</h3>
<ul>
<li><a href="https://www.mindtheproduct.com/only-losers-average-losers/" target="_blank" rel="noopener">Only losers average losers</a></li>
<li><a href="https://www.mindtheproduct.com/naimish-gohil-know-your-user-adapt-your-product/" target="_blank" rel="noopener">Naimish Gohil – Adapting Your Product for a Changing Market</a></li>
<li><a href="https://www.mindtheproduct.com/to-pivot-or-to-not-a-guide-to-executing-a-product-pivot/" target="_blank" rel="noopener">To pivot or to not: a guide to executing a product pivot</a></li>
</ul>

Getting out from the Valley of Despair in product

Sharon Feldstein

Read more

Comments