Product Managers are, by nature, problem solvers – and sometimes, they may jump into talking about solutions before fully understanding the problems that a product is attempting to solve. Given tight deadlines and the pressure to get to market quickly with innovative products, many Product Managers feel the need to propose product features and changes they think will meet customer needs. However, this can backfire if you fail to thoroughly define who your customers are, their pains, and their potential gains.
According to Principal Consultant and Trainer, Ken Feehan, the best Product Managers have spent a lot of time in “the problem space” before moving to “the solution space.” “The goal of staying in the problem space is to influence and inspire developers to create a product that customers want,” he said. “It enables you to be significantly more effective with your products and more valuable in the marketplace.”
In a recent webinar, Ken and Productside’s CEO Rina Alexin explored what it means to stay in the problem space, and how developing detailed user personas that define the problems they’re facing can be inspirational to Product teams.
Over the past two decades, Ken has learned that talking about solutions in meetings with developers isn’t always effective. “During the first half of my career, I spent a lot of time closely aligned with engineering,” he said. “Whenever there was an opportunity to meet with the user experience team or engineers and discuss how the product should work, I would come prepared with charts and graphics and mockups, wanting to be heard.”
Unfortunately, Ken found this to be a losing battle. “They didn’t listen to me,” he said. “For the first 10 years of my career, I wasn’t very effective about influencing the design of the product.”
That all changed when Ken went to work at Intuit. “Intuit did it differently,” he said. “Product Managers brought life-sized images of target customers with their problems clearly articulated into meetings with developers and sat quietly, listening to the Product Team figure out the best ways to solve those problems.”
Ken adopted that approach, as well, and found that he was much more influential in affecting product design. “I started setting up meetings to focus on the needs of specific types of customers instead of arguing over specific product features,” he said. In other words, he moved from spending too much time in the solution space to spending more time in the problem space – and it worked.
Determining whether you’re in the “solution space” or the “problem space” is as easy as observing what questions are being asked. If you’re in the solution space, common questions include “How will it work?” and “How will it look?” If you’re in the problem space, you’re asking:
“It’s very hard to influence developers from the solution space,” Ken said. “It becomes a democracy, and you’ll be outnumbered.” Instead, you should ask questions that make developers contemplate whether they’ve designed the product in a way that meets customers’ needs by going deep into the problems they want to solve. “If developers start saying that the product isn’t doing enough for the customer, you know you’re on the right track,” he said.
Problems are rooted in customer pains and gains – and you should use those parameters to build detailed buyer personas. Ken recommends holding a small number of customer interviews and asking specific questions about their pain points and desired outcomes. He also recommends using a prioritization tool – even something as simple as Excel – to prioritize customer problems following your research. This ensures that you don’t overwhelm your development team. “Choose the most valuable problems to solve, and get them into development,” he said.
Creating buyer personas, Ken said, is in alignment with the Lean Product Development process. “Our goal is to be curious about the problems customers have and continually iterate on our product to address them,” he said. “We create hypotheses, test them, and learn from them, then iterate in a continuous loop of improvement. That’s Lean thinking.”
Personas are meant to represent the needs of market segments that your product can potentially address. Ken recommends creating a limited number of personas, and two are essential:
One caveat for general-purpose tools: These may have many different types of users, requiring you to develop multiple user personas.
Ken recommends creating life-sized persona posters, complete with photos of people that represent the target buyers. Including customer quotes also inspires developers to empathize with the hypothetical target customer and see things from their perspective. Below is an example of what your persona poster might look like:
Persona Poster
What if you have many buyer personas? Ken suggests focusing on one per quarter. “It’s possible to actually build your product roadmap using personas, and focus on a set of product improvements that solve one type of buyers’ problems each quarter,” he said. “In an Agile development environment, you can bundle multiple sprints together and announce it in a press release. You can also launch a marketing campaign around the effort to demonstrate that your company is continually making improvements that directly impact buyers, throughout the year.”
As you embrace the idea of living on the problem side, it’s a good idea to sit down with your manager and explain your new approach. That way there are no surprises.
Spending more time on the problem side will deliver many benefits, including better solutions for customers, better relationships with developers, and better partnering with Sales and Marketing. As an added bonus, once your Manager sees that you have more influence over the direction of the product and how it meets customer needs, you just might get that promotion you’ve been hoping for!
Productside’s flagship Optimal Product Management (OPM) course will teach you how to spend more time on the problem side, so you can better influence product development and be more strategic. Courses are delivered either in-person or online, so you can choose the option that works best for you.
Most product teams don’t fail because they can’t ship. They fail because product discovery didn’t do its job. As product managers and product leaders, we’ve all lived this
Product management feels harder than it should It’s not because teams are lazy. Not because PMs
By the time a product launches, most teams feel like they’ve crossed the finish line. In reality, that’s where
