Building the Right Things - Product Dilemma

You have a business outcome in mind and started on a venture to build or enhance a product. You can add many features and go in multiple directions. How do you know which ones are the right ones to execute? I know the feeling.

Direction and speed are two essential parameters for anything we do; very much applicable if you are in the business of software development. The first order of business is how do I know, as a Product Manager, that I am moving in the right direction. Perhaps you are more humble and can approach the question from how do I know I'm less wrong and investigate further.

If you focus solely on speed to start with, you will measure development velocity or inject your favorite jargon from your preferred development methodology. Talk about story points delivered, and so on. That's a sure shot way to become a feature factory and, even worse, a sweatshop. (It's not the issue of methodology, it's the singular focus on speed)

Product Manager's Dilemma

Knowing whether you are moving in the right direction is undoubtedly essential. Product Management plays a huge role in answering that question, not once or twice, but at regular intervals as long as your product is in existence.

While Product Management is getting established as a critical and integral part of software development, we see more studies citing that:

• "Fewer than half of the Product Managers feel prepared to play the roles expected of them or grow into future product leaders." (Source: McKinsey & Company, 2018).

• Their biggest challenge is 'setting the product roadmap priorities without customer feedback or market feedback (25%), which is closely followed by 'getting consensus on product direction (23%)' (Source: ProductPlan’s Product Management 2020 Report)

(Source: ProductPlan’s Product Management 2020 Report)

There a skills issue (which requires a separate post), but it's useful to understand that along with the other set of challenges: roadmap, prioritizing, and consensus-building.

What is a Product?

Let's take a step back and define what a product is. There are several conventional definitions, but what I like most is Marty Cagan's definition, which hits the bullseye. He describes this with an equation:

Product = Customer x Business x Technology

A successful tech product has to solve for the customers, has to solve for our business, and has to solve for the technology.

A product is about customer's desirability/usability, business viability, and technology's feasibility. Note that the right-hand side is not an addition (+) but multiplication (x), each component amplifies the product. On the flip side, not solving for even one of the components, the value of the product tends to zero. Multiplication of anything with zero is zero, of course.

This definition is an eyeopener. You may have heard some variations of these statements if you have been in the field for a few years:

"I have the best technology fault-tolerant, highly-available, modern tech stack (add your favorite buzzwords) ..."

"You know, developers are dime-a-dozen, the product is all about business, and here, look at my shiny business plan."

"Customers are always right; we should not build anything without their buy-in."

Every one of these statements is flawed: some are beyond ridiculous. Technology is a means towards an end, not an end in itself. Business viability is essential, and business plans are useful but not sufficient for delivering the product that you take pride in. Finally, no, customers are not always right. It's not their job to tell you what your solution should be. Don't get me wrong -- customer feedback is vital. You should do everything to shorten the feedback loop. Talk to them as often as possible, every week or two, if you can. However, it's not the customer's place to design a solution.

Bring Clarity Using These Approaches

Customer connection. Enroll customers for developing a solution together. Do whatever it takes, there is no suitable replacement for a real customer. Bring in several of them. A diverse set of customers is a fantastic opportunity to leverage. If for whatever reasons, you cannot connect with customers, the alternative (a poor second, but will take it) is to collaborate with a proxy who knows the customer well. In this case, I would look for more than one proxy so that you have more information, hopefully, a better noise-to-signal ratio.

Understand Customer Jobs. This topic requires a book; a blog post cannot make justice. Fortunately, Alan Klement wrote a book that's a must-read. Some snippets:

Definition: A Jobs to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her.

Understand the demand generators and reducers

Two groups of forces work against each other to shape customer demand. The first group is push and pull, or the forces that work together to generate demand. The other group is inertia and anxiety, or the forces that work together to reduce demand. In the middle, you have the customer, who experiences all these emotions at once.

Thinking in systems — looking at the whole instead of parts of the system can help provide valuable insights. Every fragment impacts some other pieces. Understanding the interdependencies of the system goes a long way in optimizing your approach.

Validate and execute in the same phase. If all that we want to know is whether our idea is going to work, guess what, we want to know that ASAP without burning a ton of cash. The most expensive to know is by building the product and then test. Too late. Prototype — fake it before making it — carve out a narrow but business-viable scope. Experimentation is the key. Do discovery and delivery in the same short cycles. It also means building the culture of not waiting for the gold-plated requirements, and learn-fast (by failing fast). Continuously, ask the question, "why are we building this?" and cross-check every week or so with the customers. This approach addresses the direction concerns with the ability to pivot quickly.

To conclude, for building anything non-trivial, don’t assume you know what customer wants. More often than not, you don’t. Getting to the customers early-and-often, learning their unmet needs and aspirations does a world of wonders. Building the right things can lead to building them right (execution).