Product Management

A plea for b2b product managers

Kevin Capel

Follow

Feb 22 · 7 min read

Too many times I have convinced myself that skipping the process of discovering the business need is worth it. After all, we have to get the project done. What good is a product if it’s not out there? If it’s not real? We don’t help anyone if we delay again— if we slow down now, suffering is assured rather than probable. I’m being reasonable and rationale — not theoretical and impractical, lost in best practice to the detriment of our progress.

Reasons product managers may be tempted to skip the business need:

• It would take forever to get the project done — there’s not enough time to ask a million questions
• We already did research on a related topic… we are just going to find the same result
• We’ve solved this problem in the past — isn’t it the same as the last time?
• We built this product and know how it should work
• The decision point is so small… it does not matter

This is a lie —the ugliest, deceitful lie I have somehow convinced myself to believe even for a moment. With rue, my heart wishes these thoughts had never been, and I pray that those that come after me may never know a day where this sentiment rings true.

Yes, this language is a bit dramatic — skipping the business need is not. As a product manager, you exist to bring the why to life. It is impossible to create a product that solves a problem without discovering the reason the problem exists. No matter how tempted you may be to skip asking the “why”:

It. is. not. worth. it.

For all aspiring, new, and established product managers, I urge you to reevaluate your relationship with the business need and restore its proper place a the top of your priorities. There is no alternative.

What is a business need?

What do we mean by “business need”? In the b2b world, the term “business need” can also be described as a “use case” or sometimes even take the form of a user story. It’s the specific rationale, thought, or action that must occur in order to get something done. Some examples:

• Requiring that a request for a bigger budget come with pre-approval so management is not caught off guard
• Reporting on KPI metrics so that managers can promote or fire based on performance
• The need to approve a document as “valid” so that someone else does not waste time by reviewing the same document

Things that are not business needs:

• The ability to increase the budget amount
• The ability to track user metrics
• The ability to mark a document as “valid”

The key difference between these two sets of statements is the why — why must one be able to do something? What specific document must be validated? Why must it be validated? What would allow someone to skip validation? Business cases reveal what is behind an action or thought — it is not the thought or action itself. In addition to revealing a single need, exploring the business need often reveals a connected, vast network of related and sometimes competing needs.

The Product Mindset

In the larger product world, it’s common to hear product management referred to as a “mindset” (like Cole Mercer does). That mindset is the practice of being discontent with descriptions of what is happening and instead searching for the motivation, reason, and emotion behind them. Here’s a simple example that illustrates the point:

Customer: Please build me a fence.

Product manager: Why do you need a fence?

Customer: So that I can keep animals out.

Product manager: Why do you want to keep animals out?

Customer: So that I can grow a garden.

Product manager: Why do you want to grow a garden?

Customer: So that I can save money

Product manager: Why do you want to save money?

Customer: Because organic produce is expensive.

If the product manager did not ask all these (seemingly annoying) questions, she would not have understood the customer’s desire to save money, specifically on organic produce. Without this line of questioning, a PM may have simply asked “Where do you want the fence? How tall?” and installed pressure treated lumber (resistant to rot but treated with inorganic chemicals) all the while compromising the whole point of creating an organic, chemical free environment that is safe for growing organic produce.

This is the PM mindset, and it’s required to excel as product manager.

Encourage the Business Need by Embedding it in Process

If you yourself are striving for better best practices or are a manager leading a team, I would encourage you to adopt the product mindset by making the business need a requirement in your daily process:

• The business need must be present in writing on any requirements specification document produced, whether that be in a JIRA story, business requirements document (BRD), or some other tool (like Whimsical, which is my new favorite product tool)
• Encourage your designers and developers to reject your cases if the business need is not present. This provides accountability and assurance that your team has the best interest of the product at heart. Commit to keeping your cool when this happens.
• Create templates or briefs that include the business need as the first required element. Capture sentiment and empathy (a different type of need) in larger design briefs or initiatives.

Skipping the Business Need Always Results in Failure

You stop being a product manager the moment the why is deprioritized in favor of something more pressing, no matter how shiny or urgent or required. Discovering the reason behind requests or actions is non-negotiable. No matter how small the development work may seem, it is essential to explore the business need every single time even if you end up where you started. When the business need is skipped by a product manager in favor or “just doing,” the following happens:

• Other members on your team fly blind — they cannot make independent decisions when inevitably something goes wrong and needs to be rethought.
• Teams are limited to only one narrow view of progress — the business need serves as a foundation and building block for further decisions. When it’s neglected, the moment you extend a feature or component, you’re doing so without the context of previous goals and outcomes. You can only see what's been prescribed vs. the big picture.
• Teams end up building something that clients don’t want — business requirement are complex. You never get it right the first time — this is almost by design. When you listen to your customers so extremely that you give them exactly what they asked for, you end up giving them something they do not want. It requires careful attention to detail to peer behind surface level asks to discover the driver for the request.
• Rationale is lost in history forever — when the business need is identified but not written down, teams fail to pass down knowledge from one situation to the next. This creates a cycle of constantly restarting from scratch. Insights are only generated at the first degree as opposed to the second or third (insights formed based on insights) which is required to bring a product to the next level.
• You cannot create mental models— every business need contributes to a metals model of how a product works, it’s goals, desires, and treasures. I am a strong advocate for using mental models as a way to generate insights. When business needs are lost to history or only available in your mind, the larger organization cannot draw their own conclusions and contribute to exploring a larger product map or product domain.

You Can Indeed Recover

Neglecting the business need will happen. As a product manager, you’ve got more things to get done than you can physically and mentally accomplish. It is inevitable that you will send work through the queue without a strong “why.” Nonetheless, your commitment to the why is more important than your actual success rate (although they are perhaps correlated *wink*).

Learn from the times that you neglect the why in favor of the desire to make a decision or move on. You may get lucky — perhaps there are no adverse consequences — however, you might end up with a few things you wish you could take back. Your mistakes here (that can live with you for a long time in software) can serve as a reminder for why the business need is essential.

Don’t become an imposter — dressed as a PM but not advocating for the why. You have enough to worry about when it comes to learning to embrace imposter syndrome already. Learn to cherish the business need as a special, and perhaps even sacred, element of the product process. Product managers cannot exist without the why — neither can sound product decisions.