And What You Can Do to Avoid Them

Disclaimer: I don’t really believe you can ‘teach’ Product Management. You can only experience it, make your own mistakes and share your insights with the community. That’s what I did in 2022 and doing so, I also got to dig into a lot of clients’ products.

Here is what I noticed.

  1. Not enough people spend enough time on defining vision and purpose
  2. Most value propositions are weak
  3. Companies don’t adapt their team typology to make a product
  4. Very few products are indeed prioritized by value
  5. User Research and UX are ofter used in the wrong way

Everybody talks about Simon Sinek’s golden circle, about Ikigai, about purpose and other synonyms, but no one really puts a lot of effort on finding purpose and meaning. Maybe because it’s never really clear whose responsibility it is to do so. And maybe because it is the hardest part of the job.

Product Managers I work with often tell me that “the purpose” has been decided by top management “a while ago”. Weird. Because when I get to talk to top management, they usually tell me they rely on PMs to work on purpose and vision. In the end, no one has really done the job.

In ten+ years of Product Management I saw more people spending an incredible amount of time discussing *how* to make the product than people asking whether they should do it at all— or what purpose it serves.

What you can do about no one defining purpose

  • It’s never too late to do good: even if the product is out, craft a vision and a value proposition. A value proposition is the benefit for the customer, the “why they should buy the product from you”. It’s not what the product does, it’s what the customer can do with the product. And a vision is a bet you place on the future that makes you think the world needs your product. You can read more about it in another post I wrote about Shaping a product.
  • Write a one-pager to clarify and align all the stakeholders on the product vision. You can have a look at this post to know more about one-pagers.
  • Try and fill a product vision board. The result is never as important as the process and all the insights it will uncover.
  • Have a look at the Shaping part of Shape Up, Basecamp’s methodology. Though it’s not about vision per se it will raise questions you need to ask yourself to craft a vision

But most of all: get back to it everyday for a few weeks to refine your thoughts for it’s a long process.

Sometimes, there is a value proposition, but it’s neither clear nor inspiring and let alone actionable. A product value proposition should be targeted and user centric, specific and unique (thus, not transferable).

  • targeted and user centric. Your value proposition should speak less about the company that builds the product than about the person that will be using it. Yet, 80% of the time I see it the other way around. Companies use value proposition to say how incredible they are, not how useful their product is for the user. That being said, your value proposition should also be targeted to a precise user segment.
  • specific: it is detailed and precise. It addresses a specific customer profile with specific needs and clearly explains how the product will meet those needs.
  • unique: two competing products should have different value propositions. That is why it is called “unique value proposition” in both the business model canvas and the lean canvas ;). Value propositions are not transferable from one product to another.

80% of the value propositions I read are vague, convey no impact and are too short. They look more like marketing slogans (“the fastest way to do X”, “the simpler way to Y”) with very subjective and abstract adjectives (“Simpler” than what ?)

If concision is a quality, the devil lies in the details and most of the time we need space to express exactly the outcomes and benefits for the customer. Don’t be afraid to write a few paragraphs.

Alan understands this. And while their mission statement is concise, they still felt the urge to write the subtitles 🙂

What you can do about weak value propositions

  • stop talking about your brand, your reputation, your incredible product. Start talking about the user’s benefit. Answer the “what’s in it for the customer ?” prompt and write it down in your value proposition. Highlight other users’ use cases and show, with examples, how versatile the experiences can be on your product. Everyone should be able to answer this question “what can I do with this product?”
  • start from the current version and relentlessly ask “how does our product differ from [other product] ?” Refine and repeat.
  • don’t be afraid to focus on details: the double tick in Whatsapp may seem like a small artifact and yet most of the product’s usefulness relies on this tiny deliverability indicator.
  • highlight or work on your unfair advantage (something only you have that makes your product different). It can be your sense of humour.
  • dig into your convictions. Don’t be afraid to let them show through your product vision. Yes, it’s risky because you make yourself vulnerable and potentially not likeable by those who don’t share your convictions. But you can’t please everybody with your product. And you don’t have to. Look at how basecamp or Hey! are different. Difference and strong takes on the world are good!
  • read this post from full of good advice by Robbin Schuurman or this one to get you started in five steps.
  • work with a product coach. Having someone from the outside bring freshness and candor and good practice can help you get out of the rut.

So, the usual path is : a company that was structured to conduct projects wants to instill a product mindset from now on. So they ask their teams to have a product training and “start doing product”. Except that product teams have a very different DNA than project teams : UX is at the core of success — the mind and soul of the product; value — not deadline and budget— is the compass and motivator; delivery capabilities are crucial — the legs and stamina; development comes last.

A product team typology is much more diverse than a project team :

  • UX activities (such as discovery and building a compelling experience),
  • Data activities (such as measuring quality and adoption or doing AB testing),
  • Validation activities (such as watching users’ funnels and logs, organizing user tests, etc.)
  • and contents activities (copy-writing, content writing and producing internal and end-user documentation)

are far more developed than in a traditional project approach. Not to mention the constant care for alignment with the business model.

In addition, in the product culture, we prefer each team member to be 100% dedicated to the product. Like in a startup. In a matrix organization where people still work in silos (departments), it’s not uncommon to share resources between several projects. This leads to disorientation, lack of focus and task-oriented team members.

“The best way to fail to invent something is by making it somebody’s part-time job.”

— David Limp, Amazon’s device chief

How you can adapt your team typology to make better products

  • Fight against resource sharing, like having your team members working on 4 different projects. It is an illusion to believe you can sustainably pursue 4 projects in parallel with shared resources. Focus and fight for a small dedicated and focused team. Spread this video.
  • Aim for small, diverse and pluridisciplany teams.
  • Differ the need for code as long as you can. Prototype everything (at least on paper).
  • Co-locate everyone if you can. Don’t underestimate the power of direct communication.

How you are structured to build the product makes 80% of the product.

Most companies that claim having a product culture continue to prioritize by time and budget, even though they claim to prioritize by value. The roadmaps look like retro-plannings and don’t highlight value. Their definition of value often revolves exclusively around ROI or brand value but rarely takes the customer into account.

Very often, they use Scrum. Which locks them into short development cycles focused on delivery (producing and releasing features) and ‘velocity as a planning tool’ instead of focusing on relevance (“should we do it?”), continuous learning and prioritization by value.

What you can do about it

  • have a thorough discussion about value and try to highlight the different shapes and colors of value for your product : usage value, future value, market value, risk control value, business value, efficiency value, etc.
  • use an acid test. As for the product vision board, the results are far less interesting than the process of building a shared understanding of what value is at this very moment. Here is Patagonia’s
  • acknowledge that value evolves with time and product maturity. Value is not static. If your product is emergent, work on increasing usage value (the value perceived by users) especially if your product relies on network effects. If the product is mature already, work on market (more shares), business value (more profit) and efficiency value (optimisations). And so on…
  • work in Kanban and make sure that your backlog is in order with the highest value-added tasks always at the top

Organizations still use User Research to take requirements from their customers. I can not emphasize enough how wrong this is. Taking requirements is great for service (“dear customers, tell us what you want and we will build it for you”), not for product. Apple never asked its customers what they wanted. Because product are driven by vision, not customers requirements.

How you can optimize user research

  • learn to figure out the business context you are working in (trying to foster innovation or service business or making a product) and adapt your UX strategies subsequently.
  • don’t use UX to take customer requirements if you seek to build a product. Use UX to uncover needs and aspirations or to validate solutions assumptions aligned with your product vision.
  • have a dedicated UX team or do UX and discovery by yourself (yes you can 😉)

Everybody expects some sort of shortcut to success in a discipline that takes years to master but there is no fast lane to Product Management.

Most people attending Product Management trainings expect quick solutions to complex problems (lack of vision, wrong strategy, no system thinking, etc.). They’re eager for tools, frameworks, recipes, canvases, success stories of companies whose examples will never be transposable to their environment.

It’ll take months, sometimes years, before we start to figure things out. Tools and quick shots don’t make you more “product minded”. Observation, reflection, curiosity, intuition, hard work, and testing do. There is no shortcut.


Source link