How Tech Product Managers Can Drive Innovation by Focusing on Customer Needs - SPONSOR CONTENT FROM CAPITALONE

By Marcie Apelt

Every product manager knows the sting of launching a feature that falls flat. Hours of engineering, design, and testing can vanish into obscurity if the problem wasn’t worth solving. The antidote is problem obsession, a discipline that shifts focus from what we can build to what customers urgently need.

Know Your Customer

Before you start building a product, it’s important to create a product strategy grounded in data-driven customer insights. That may sound obvious, but I’ve seen instances when a product was built because it was a “cool thing,” and then that thing never made it off the shelf.

A strong product strategy ensures you’re creating the right product for the right audience, and it helps mitigate the risk of building something that doesn’t solve customers’ needs. It also requires clear stakeholder alignment before you begin the build. In particular, if you’re building foundational technical capabilities, it’s critical to make sure the teams that need to translate that capability into an end-user experience are excited about that work and can staff it.

The first step in creating a product strategy is having a solid understanding of who the customer is and the problem you’re trying to solve.

Let’s start with the customer. Say you’re building a platform to enable the creation and execution of models. You could decide to build for two very different types of users: extremely technical data scientists who are coding new machine learning models and data scientists who want to modify logic quickly without having to code themselves or get the help of an engineer.

The needs of these two personas are dramatically different, so there is tremendous value in getting a clear understanding of who your target audience is and what its corresponding needs are. Even if you think you know who your customer is, it’s crucial to dig even deeper into that customer persona to tease out exactly what’s driving that need—soliciting and incorporating user feedback all along the way—so users are eager to use your product as soon as you deliver it.

Once you’re aligned on the end user, it’s time to get laser focused on their needs by asking questions and obsessing about how your product strategy will meet those needs.

You and your stakeholders should align on the answers to some fundamental questions before you start:

• What problem are you solving?

• How will solving that problem drive business outcomes?

• How can you deliver the solution iteratively, gleaning insight and learning along the way?

Once you have a good understanding of the problem, it’s important to align with your stakeholders on priorities, expected value, and resource allocation to build a rightsized solution you can continue to iterate on. Developing a strong business case grounded in analytics will give you answers to these questions and set you up for success.

Use Analytics to Determine Priorities

There are often multiple paths to solving the problems your product aims to address, each with clear pros and cons. As a product leader, it’s your job to make deliberate and strategic choices. There’s never a shortage of good ideas, so it’s important to quantify the problems and the potential solutions through an objective business case.

This analysis—understanding the size of problems and the precise value you’re trying to unlock—is an important part of product management. We might create value by making it easier for end customers to use a product, or we may aim for future value by developing an internal tool to speed up the deployment process. Quantifying and prioritizing based on the value a capability unlocks is a cornerstone of the practice.

But alongside the value it unlocks, also consider the resources it requires. There’s a triangle of constraint between the desired time to market, the level of resources required, and the refinement or breadth of features in a product.

Whichever constraints are at work, it’s important to be very clear on how that combination affects the other aspects, such as the feature set available at launch, the date it will be available, and which other projects you may need to deprioritize. If stakeholders have clarity on all these items, it becomes easier to avoid disappointment and also to make good trade-offs as things come up along the way.

Start with a Steel Thread

Once you’ve established the product strategy, it’s finally time to build. The key is to start small and then iterate.

Civil engineers use a methodology called the “steel thread approach” to build a bridge. They start by shooting a steel wire across the chasm, and then they use that wire to transport building materials for the next part of the bridge, and so on until they’ve reached the other side.

Your organization can take a similar approach by starting with a very thin foundational layer of code and iteratively building upon it to reach the target state. With this approach, all the components are built and connected, but each initial component likely has limited functionality in itself.

If you are building a platform to determine whether to approve or decline a credit card transaction, your product needs to make complex decisions in less than one second. The first steel thread solution should be simple but still test the card’s ability to let the customer make a purchase and get a yes or no back (approve a purchase under $100, decline a purchase over $100). Over time, you could add more sophisticated logic using machine learning models to consider a myriad of inputs, such as credit limits and potential fraud—all within one second.

Starting small doesn’t necessarily mean small results. I like to scope something that has real business value early on, even if it’s a thin launch, by asking the team, “What is the most narrow thing we could do that still achieves a valuable business outcome?” More often than not, there is big value in knocking out the first few low-hanging fruit problems.

One important thing to remember: Even when you’re starting small, you need to work back from a well-thought-out destination. In particular, you need to create the architecture with all the end-state capabilities in mind even if you will likely release capabilities over time.

Feedback Drives Iteration

Soliciting iterative feedback provides the opportunity to engage in a dialogue with customers as the product evolves. Continual user testing and feedback is vital. It helps to clarify the problems, which might be different from the ones you anticipated. It also helps inform your priorities for next steps and avoid wasting time on refining paths that are less important to end users.

Customers are very often delighted to be involved. We worked on a platform to create AI models for some of Capital One’s senior data scientists. They were thrilled to participate and pulled apart our initial iterations. One scientist came back with a 20-page dissertation on everything we could do better. That may sound painful, but it was incredibly helpful. We improved nearly everything our data scientists critiqued and ended up with a stronger product and happy customers—a win-win!

Product success rarely comes from clever features alone. It comes from the discipline of defining the right problem, validating it with data, and aligning stakeholders around a strategy to solve it. Leaders who cultivate this obsession with customers’ problems set their organizations up not just for launches but for lasting impact.

The next time you start scoping a product, pause before sketching features. Ask yourself instead: What problem are we solving, and why does it matter?

Learn more about how product managers can drive meaningful innovation by focusing on customers’ needs.

Marcie Apelt is SVP for Product Management in Card Technology at Capital One.