User-Centric Development

It seems simple enough: We’re building a product to sell to a customer, therefore we must build a product customers want to purchase.

In many cases, that simple idea is easily forgotten under various guises, such as needs of the business, technical debt, or “they don’t know what they need, we need to teach them!” There are countless arguments to get away from user-centric development, but we only need one good reason to stay focused on it: someone needs to buy your product. I’ve heard from CTOs and Directors of Product, on multiple occasions, that I need to “design it for the CEO, and forget about what the customers are telling you.”

This comes after spending thousands on customer roundtables, interviews, and other various research methods to establish what those very same customers are most interested in. But the CEO runs the company, and he believes, for one reason or another, that we should build the product he wants, not the one they want. Which is interesting considering he’s not planning to support the company out of his own pocket – he won’t be purchasing the product; he needs interested customers for that.

All too frequently we have stakeholders focused on their version of a product, and it’s our job, as Product Managers, Product Engineers, and really anyone involved in the product-definition process, to navigate those conversations diplomatically. We need to take care to not push our version of a product the same way our stakeholders do, but rather establish methods, means, and solutions to determine the optimized product-market fit for our end-users. Will there be tradeoffs? Sure, nearly every product has tradeoffs, but until we identify and define that truly transcendent product, our development process, and the tradeoffs we make, can’t really be considered valid – if we don’t know what we’re giving up, how can we be sure it’s worth trading?

As Product Managers, we have a few avenues to interface with customers. Our Sales and Farming Staffs are one option; we can review notes with them to hear the feedback they’re getting, how they win or lose customers, and being often paid on commission they can be a truly valid source of quality, revenue-minded information. When we win a new customer: why? What did they like, and why did they choose us over the competition? When we don’t win we can often learn even more: what did the competitor have that we didn’t? What would they like to have seen from us to make a different choice? Incorporate that information into your product strategy.

Another option is to talk to customers yourself. Product Managers are often called the voice of the customer, and that comes mainly from two places. The first is creating user stories for development – Jira or another platform of choice – where we define requirements from the user’s perspective. These are often written in the form “As a user, I want to be able to [do this thing with your product].” The second primary reason is because it’s the Product Manager’s job to bring that customer mentality to every stakeholder meeting and vouch for them. When an engineering manager is fearful of a technical challenge, or pushing something overly challenging, or when an executive keeps claiming to know the absolute unquestionable best direction for this product, it’s our job to speak up for our current and/or future customers. “No” is one of the most important words in the PM’s library, and we must invoke it diplomatically to be sure our customers’ voices are truly heard.

Be sure that your framework, and your process for defining and refining your product, is based on the actual Users. Every feature, bug evaluation, process, and scorecard should come back to your User – what does it provide them, what does it take away from them, and how does it ensure the best possible adoption for our customers? Once this is established, you can begin reviewing prioritization, value, complexity, and debt to determine the best path forward.

May 14, 2020