The Problem-Solution Space

Welcome, Topic & Introductions

Rina Alexin | 00:00:00–00:03:15
Hello everyone, welcome and happy Thursday. Thank you so much for joining us for another installment of our Product Management Leadership Series.

Today we’ll be discussing the very familiar and very critical topic of staying within the problem space.

My name is Rina Alexin and I am the CEO here at Productside. I’ve been leading the company now for the past four years—four short years, right Ken?—and we’ve been focused on bringing transformational change to product management teams everywhere.

A common problem that we see—and I include everyone in this, including myself—is our tendency to jump to solutions instead of staying with problems. The best product managers know that before going into the solution space, they must really thoroughly understand the problem.

That’s the focus of today’s webinar. If you enjoy and like what you hear today, I encourage you to check out our other resources on our website, as well as our Optimal Product Management course.

I’m excited to introduce you to Ken Feehan. Ken, I’m not allowed to play favorites, but I’ll tell them all—I’ll tell them all—but I’m really excited to be doing this webinar with you today.

For our audience: Ken is one of our principal consultants and trainers at Productside. He has deep experience in product development and the go-to-market phases of the product lifecycle. He has worked and consulted across hardware, software, cloud infrastructure, and services companies, and he understands the business needs of each.

He has over 20 years of product management and product marketing experience, coming from top companies like Apple, Intuit, Dolby, as well as many startups and smaller tech firms.

Thank you so much for being here today, Ken.

Ken Feehan | 00:03:15–00:04:22
Excellent, thank you, Rina. Thank you for allowing me to talk about one of my very favorite and most influential topics. This is one where, if we can get a product manager to live on the problem side, we can change their career and get them promoted.

You are talking my language, and I’m very excited.

Before we get going with the webinar, I’d like to go over a few housekeeping items.

Housekeeping, Community & Logistics

Rina Alexin | 00:04:22–00:07:05
First, after this webinar, continue to stay engaged with the product management community by joining our LinkedIn Product Leadership Group. You can use it as a forum to chat about best practices and share tips. We’ll be pasting that URL in the chat box, and we’ll keep sharing it throughout the webinar.

Throughout this session, we want to encourage you to interact with us and ask questions.

Ken, if you can advance the slide:
You can use the Q&A box at the bottom of the screen to type in questions at any time. If you want to use the chat box, I’ll be monitoring that as well.

In fact, Ken, with your permission, if there are relevant questions, I’d like to bring them in while we’re talking live. Is that okay with you?

Ken Feehan | 00:07:05–00:07:24
Yeah, no, that would be great. I would love to make this more of a discussion and a little bit less of a lecture, so yes—let’s take questions as they come in.

Rina Alexin | 00:07:24–00:08:09
Great, that’s what we’ll do. We will be leaving time for Q&A at the end, so we’ll have plenty of opportunities to answer your questions as well.

Let me answer the most common one right now:
“Can I watch the webinar later?”
The answer is yes. All attendees will receive a link to view the webinar recording after it has ended.

Now, the agenda for today:

Ken will be going through how to stay in the problem space, starting with defining what the problem space and solution space are. He’ll go over some topics from lean thinking and show you how to further leverage personas and bring those problems to life.

But first, I’ll go over just a little bit about Productside.

About Productside & Our Focus on Product Professionals

Rina Alexin | 00:08:09–00:09:35
Our mission at Productside is simple: we want to empower product professionals with the knowledge and tools to build products that matter.

Unlike many other companies, we are focused specifically on the needs of product professionals everywhere.

Whether you are investing in your own knowledge and skills to advance your career, or you’re a leader working on improving your team’s effectiveness, we have the experience and customized services to get you to the next level.

Check us out at Productside.com—we’ll paste the link in the chat as well.

Now we’re going to get into the meat of the webinar, and we always start with a poll.

Poll: Are You Problem-Side or Solution-Side?

Rina Alexin | 00:09:35–00:10:39
The poll should be launched now and it’s quite simple:

“Are you a problem-side or a solution-side product manager?”

And of course, for those of you who are confused, there’s my favorite third answer: “Huh?”

We already have at least one person saying “Huh,” Ken.

Ken Feehan | 00:10:39–00:11:10
Then they’re in the right place.

Rina Alexin | 00:11:10–00:11:43
Yes, you’re all in good company.

Based on these poll answers—very interesting—we’ve got an even split between problem-side and solution-side PMs, and we’ve got at least a few confused souls out there.

Ken Feehan | 00:11:43–00:12:40
Oh, that’s fantastic. It means that the content we’ll present over the next 30 minutes or so is going to hit home and, hopefully, inspire some people to get to that next level of productivity in terms of product management.

Thank you for the introduction, Rina. Let’s go ahead and get into the discussion.

From Solution-Space Habit to Problem-Space Influence

Ken Feehan | 00:12:40–00:17:50
I think I’m really qualified to talk about being a problem-side product manager because I spent the first half of my career fighting against it.

In the beginning of my career, I spent a lot of time very closely aligned with engineering and development. Whenever there was an opportunity to meet with UX people, UI designers, or engineers and talk about how the product would work—how many buttons it would have, whether it would be on mobile or in a browser—I was gravitationally pulled into those meetings.

I’d show up with charts, graphics, mockups, and I desperately wanted to be heard in those rooms. But if you think about it, that was kind of ridiculous:

• We had professional UI designers there.
• We had engineers who knew the code inside and out.
• There were usually six engineers, two UI folks, and then me—the inexperienced 20-something product manager.

I felt it was my birthright as a PM to help define and design the product: to argue about whether there should be two buttons or three, whether it should be green or blue. But their ideas were almost always better than mine, and there was a little bit of arrogance too—they didn’t always listen to me.

I was drawn to those solution conversations, but I frequently left those meetings feeling frustrated and not influential. For the first 10 years of my career, I was not very effective at influencing product design because I was approaching it wrong. I was approaching it from: “Please listen to me,” instead of doing what a real product manager should do.

After leaving “the fruit company” and some of those bad habits behind, I had a stint at Intuit. Intuit did product management very differently than Apple. They still had those engineering and UX-heavy meetings, but the expectation of the product manager was different.

The PM’s job was not to argue over button colors. The PM’s job was to bring in personas and customer problems.

They literally brought in life-size persona posters. Each one had a persona name, job title, maybe a couple of quotes about the problems they faced. There would usually be two or three of these in the room.

Our job as product managers at Intuit was to:

• Establish these personas,
• Represent the customer problems they stood for, and
• Make sure everyone in the room was focused on building solutions for those specific problems.

When I went into those meetings with personas and clearly framed problems, I suddenly became hugely influential—not because I said “the button should be blue,” but because I set up the meeting to focus on:

• Who is the customer?
• What problem are we solving?
• Why is it valuable enough that they’d pay us to make it go away?

The engineering team actually demanded that from us. If we weren’t specific enough about the customer problem, they pushed back.

That approach—making the customer and their problem the star of the meeting—made us much more influential and led to better products.

Rina Alexin | 00:17:50–00:18:44
I can definitely attest to that, Ken. Even at Productside, whenever we have a discussion, you always bring it back to the persona.

This also reminds me of the empty chair practice—like at Amazon—where the empty chair represents the customer. Now we can have the “empty Zoom box” if you will.

Ken Feehan | 00:18:44–00:19:45
Exactly. And Rina, here we are—a bunch of seasoned, crusty product managers in a room. We love to jump into solution space. We love to say, “Oh, it should be an email,” or “We just need a new dashboard.”

But the discipline is to stop and say:

“Don’t tell me about the solution yet—tell me more about the problem.”

When we do that, we end up with better solutions, usually faster.

Defining Problem Space vs. Solution Space

Ken Feehan | 00:19:45–00:24:06
Let’s talk about these terms explicitly: solution space and problem space.

If you’re in a meeting where people are asking:

• What size should the button be?
• Should this flow be on two screens or three?
• Should it be mobile-only or desktop?

You are in the solution space. That’s where you talk about how things will look and behave.

The problem with spending most of your time there is:

• It’s usually a room full of people whose job is to design solutions (engineers, UX, UI).
• If you try to fight on that turf, you’re often outvoted 8-to-1.

You’re just another opinion in a sea of opinions.

If you are living in the problem space, the questions you’re asking and answering are different:

• Who is the customer?
• What problem are they trying to hire us to solve?
• Why is this user more important than other users?
• Of all the problems they have, which are the top priorities?

If you are the product manager operating in the problem space, you’re the one saying:

“Here is the target persona, here is their situation, and here are their top problems.”

That’s where your strategic influence lies.

Rina Alexin | 00:24:06–00:24:40
Quick question, Ken. We saw in the poll that a lot of people identified as solution-space product managers. You’re not saying a PM should never live in the solution space, right?

Ken Feehan | 00:24:40–00:26:04
Correct—I’m not saying “never.” You absolutely will and should enter the solution space. The key is when and how.

You want to spend more time than you probably do today in the problem space, and only move into the solution space after you’ve:

• Established a clear, structured problem,
• Identified a real persona, and
• Prioritized what matters most.

There will be plenty of people ready to brainstorm solutions. But there’s usually only one person in the room whose job is to keep everyone honest about the customer and the problem—and that’s you.

Audience Question: Where Does the Problem End and Solution Begin?

Audience (Phil) & Ken Feehan | 00:26:04–00:30:20

Phil (Audience)
I get the principle, but it’s sometimes hard to know where the problem ends and the solution starts. I was never a developer, so I don’t have that bit. I never say “the box should look like this,” but we do get requirements like “we need it to do X or Y,” and that feels different from “what’s the business problem you’re trying to solve?”

Ken
Great question. You’re not alone in that. It is a gray line sometimes.

The way I think about it is:

Before we allow ourselves to brainstorm solutions, we do a quick inventory of whether we’ve done enough problem work:

• Do we have a clear persona?
• Do we know their context and goals?
• Have we written down three or four key problems they want us to solve?

If we’ve done that well, then we’re ready to move closer to the solution space. If we haven’t, and we’re already debating user flows, then we’re probably sliding into solution space too early.

So if you’ve built your persona and captured good problem statements, then yes, you can start moving into that transition zone with less risk.

Phil
Makes sense. Thank you.

Pains, Gains & Lean Thinking

Ken Feehan | 00:30:20–00:35:53
As you’re representing customers in these meetings, I pay special attention to pains and gains.

When I interview customers for a persona, I ask:

• What’s hard about doing this today? (Pains)
• What would delight you or make this dramatically easier? (Gains)

Examples of pains might be:

• “I have to copy-paste the same data five times.”
• “I can’t do this on mobile while I’m on the go.”
• “It takes me 20 minutes just to do a basic task.”

Examples of gains might be:

• “If this pre-populated the fields, I’d save so much time.”
• “If I could do this from my phone while waiting in line at Starbucks, that’d be amazing.”
• “If it remembered my preferences, I’d avoid repetitive clicks.”

I then encode these pains and gains into the persona:

• In their quotes
• In the “a day in the life” description
• In what success looks like for them

This connects perfectly to lean thinking.

We:

• Form a hypothesis about the problem.
• Talk to several customers to validate or refine it.
• Test the most promising ideas.
• Learn, then loop back.

Lean helps us avoid building custom one-off solutions for a single loud customer. As product managers, our job is to build something once that we can sell a thousand or a million times—not custom code for one client.

Lean discovery around shared problems is how we get there.

Poll: Do You Use Personas?

Rina Alexin & Ken Feehan | 00:35:53–00:39:35

Rina
We have another simple poll:
“Do you use personas?”

Options:

• Yes
• No
• I think the sales team uses personas
• I’d like to learn more before I answer

We’re seeing about two-thirds say “yes,” and about a third say they want to learn more. A few say “no” or “sales has them.”

Ken
That’s fantastic: more than half the group uses personas as product managers. If you already use them, I hope I can give you at least one new trick. If you don’t, I’ll give you a starting point and a way to make them truly useful.

Personas: Users vs. Buyers (And Why You Need Both)

Ken Feehan | 00:39:35–00:47:35
Personas are your friends as a PM. They represent the needs of a market segment you want to serve.

The key insight for me was:

• You don’t want 1 persona.
• You don’t want 10 either.
• You typically want 2–3 core personas, not 20.

My favorite pattern is to always have at least:

1. A User Persona – someone who uses the product every day.
2. A Buyer Persona – someone who decides to pay for it.

User persona examples:

• A shopper opening the Target app on their phone.
• A salesperson who logs into Salesforce daily.

They interact directly with the product. You want the product to be useful and pleasant for them.

Buyer persona examples (B2B):

• The VP of Sales or Sales Operations who signs the Salesforce contract.
• The IT or procurement person who owns the budget and approves the vendor.

They might not use the product daily, but they decide whether to spend money on it.

If I only get to create two personas, I always create:

• One user
• One buyer

For the user, I focus on:

• Their workflow
• Their environment (e.g., “standing in line at Starbucks, trying to quickly update a record on their phone”)
• Their pains and gains

For the buyer, I focus on:

• Their job title and responsibilities
• Budget constraints
• ROI, risk, compliance, and strategic goals

I name them, give them a real face, and write quotes they might actually say. For example:

“I’m on the road all day, going from call to call. I have five minutes in between meetings and I need to update the system quickly while standing in line for coffee.”

Now, when we’re writing user stories or debating solutions, we’re asking:

• “Does this help Fred the Sales Rep?”
• “Does this create value Betty the VP of Sales will pay for?”

Those personas come with me to every meeting.

Audience Questions About Personas

Rina & Ken | 00:47:35–00:56:40

Q: How hard is this to apply to machines or hardware (e.g., cement barriers, laptops)?

Ken
This absolutely works for hardware and physical products.

I had a student who worked on cement freeway barriers and asked, “How do personas apply to that?”

We created a user persona:

• The worker who unloads the barriers from the truck,
• Has to connect them safely,
• Under time pressure, in dangerous conditions.

We created a buyer persona:

• The government or municipality official buying the barriers,
• Concerned about safety, durability, regulations, and cost.

Same method—different domain.

Rina
I’ll add: for laptops in a company, the user is the employee, and the buyer is IT or procurement, who cares about security, standardization, supplier relationships. Same idea.

Q: What about products used across many industries, like Excel? Do we need personas for every vertical?

Ken
Great question. For broad tools like Excel, you’ll never model every single possible user.

Instead:

• Identify a few high-value segments or archetypes.
• Create strong personas for those.
• Rotate focus over time.

For example, one quarter you might focus on:

• “Data Analyst at a tech startup”

Next quarter:

• “Finance Manager at a mid-size business”

I sometimes plan a quarter around one persona, choose backlog items that best help that persona, then at the end of the quarter:

• Ship improvements,
• Publish a release note or “what’s new for analysts,”
• Brief sales and marketing around that story.

Over time, you uplift the experience for multiple personas without trying to boil the ocean in a single release.

Rina
Companies often do this via persona-specific templates or onboarding flows—for example, marketing templates vs. finance templates—still one product, but tailored starting points for segments.

Examples of Problem Statements vs. Hidden Solutions

Ken Feehan | 00:56:40–01:00:12
To make this real, let’s look at some example statements and ask: are these problems or solutions?

• “As a parent, I want to avoid filling landfills with dirty diapers.”

That’s a problem (or a need/value).

• “I want the process to autofill address info for the customer.”

That’s partly a solution hint. The underlying problem is more like:

“I want to process more invoices per hour and avoid repetitive data entry.”

• “I want to be green but I don’t want to spend more.”

That’s a constraint plus a desire—a very real problem to frame.

Buyer-side examples:

• “As a manager, I want to process more transactions per hour without increasing staffing costs.”
• “As a supervisor, I want my people to do fewer manual interventions.”
• “I will only work with vendors who conform to zero-waste policies.”

These are great problem statements to put into persona bubbles and build around.

Persona Templates, Quotes & Getting Customers Promoted

Ken Feehan | 01:00:12–01:05:25
Here’s how I like to structure a persona:

• Name and photo (realistic, not stock-cheesy)
• Role and context
• Quotes that they would actually say
• Goals, pains, and gains
• What would get them promoted

That last part is powerful. I like to explicitly ask:

“What would make you look like a hero in your organization?”

If I can help them:

• Increase throughput,
• Reduce waste,
• Improve customer satisfaction,

I’m not just selling them a product—I’m helping them advance their career.

If you can build a product that gets your users and buyers promoted, they become extremely loyal advocates.

I also physically bring these personas to meetings—on posters, slides, or even as a Zoom background. They become “virtual participants” in the conversation, and it’s very hard for a team to ignore a face with a quote above it saying, “I spend 40 minutes a day on this task.”

Prioritization: Avoiding 20 Unsorted Problems

Ken Feehan | 01:05:25–01:08:12
Customers are going to tell you they have a lot of problems. Not two. Twenty.

If you just dump all 20 on engineering, nothing good happens.

Use a simple prioritization model—a spreadsheet is fine. For each potential problem/feature, score it on a 0–5 scale for things like:

• Impact on user happiness
• Revenue impact
• Competitive gap closed

Then total the scores.

Once you’ve done that yourself, take it to others:

• Dev lead
• Sales lead
• Maybe support or customer success

Ask them:

“Did I get this right? What would you adjust?”

You become a data-driven product manager, not just “the person with opinions.”

You can even add a column for growth potential to make sure you invest in emerging segments, not just current revenue.

Using Personas in Agile Roadmapping

Ken Feehan | 01:08:12–01:12:02
If your company uses Agile with, say, four-week sprints, there’s a nice way to layer persona strategy on top.

The backlog might be full of stories. Instead of pulling them randomly, for a given quarter you can say:

• “This quarter, we’re focusing on Betty the Buyer,” or
• “This quarter, we’re focusing on Eugene the Everyday User.”

Then you:

1. Choose backlog items that best serve that persona.
2. Build and ship those.
3. At the end of the quarter, tell a story around it:

• Release notes,
• Sales briefings,
• Webinars,
• Blog posts.

You’re still Agile, still responsive—but you’re also telling coherent persona-based stories to the market.

Your Role in the Next Dev Meeting

Ken Feehan | 01:12:02–01:15:38
At your next meeting with your development team, your job is to:

1. Establish personas with clear, prioritized problems.
2. Bring them into the room—literally or figuratively.
3. Create a safe environment for brainstorming and questions.
4. Let the personas do the work.

Instead of walking in and saying, “Here’s my solution,” you walk in and say:

• “Here is Fred, here is Betty.
• Here’s what their day looks like.
• Here are their top three problems.
• Let’s brainstorm how we might help them.”

You’ll know it’s working when an engineer says something like:

“We’re not doing enough for Betty the Buyer—we need to give her more.”

That’s when you’ve changed the culture.

I recommend also sitting down with your manager and saying:

“I’m going to change how I do product management. I’ll be spending more time in discovery and problem space and less time in tactical solution debates.”

Don’t surprise them; bring them along.

And yes—print those big personas.

Q&A: B2B vs. B2C Buyers, Elon Musk, Sales Personas & More

Rina & Ken | 01:15:38–01:26:50

Q: Are buyer personas only relevant in B2B?

Ken
In B2C, the user is often the buyer (e.g., you subscribe to Spotify yourself). In that case, one persona can cover both usage and purchase.

But even in B2C you can have separate buyers and users—for example:

• Parents buying for children,
• Gift scenarios,
• Household decision makers vs. actual users.

In B2B, the user and buyer are almost always different people. So in B2B, having both personas is critical.

Q: How would you explain someone like Elon Musk—great at both problem and solution space?

Ken
There are a few people—Steve Jobs, Elon Musk, Jeff Bezos, Bill Gates—who operate at a different altitude. They seem to naturally bridge problem and solution in extraordinary ways.

I don’t think most of us should try to “be Elon.” What we can do is build robust, teachable practices for the other 99% of product managers:

• Deep problem understanding,
• Strong personas,
• Clear value propositions,
• Data-driven decisions.

Elon still starts with massive problems—sustainable transport, space access, etc.—so he’s very much a problem-space thinker. The rest is genius we don’t need to copy to be effective.

Q: Our sales team has personas. Can’t we just use those?

Ken
Sales personas are often designed to guide which customers to call on and how to pitch. They’re valuable, but they are typically optimized for the sales process, not for product design decisions.

I like to:

• Thank the sales team for their work.
• Use their personas as a starting input.
• Then refine or create product personas focused on usage, pains, and value in the product.

They’re related but not identical.

Closing & Next Steps

Rina Alexin | 01:26:50–01:30:15
Thank you so much, Ken, for all this great advice. You’ve inspired me—everyone on our product team is now going to get a new Zoom background with a persona in it.

If you liked what you heard today and want to continue learning all the core skills to build and manage products that matter, check out our Optimal Product Management course. We have one starting in just a few weeks on May 3rd, and for attending this webinar, we have a special promotion for $500 off the next live online course.

We also have a digital course option if you prefer self-paced learning.

We’ll now launch our final poll to hear your feedback—please let us know if this webinar was helpful. We do listen to your feedback when designing new topics.

Our next webinar is on Seven Reasons Products Fail, with our colleague Kenny Kranzler and Jake. It’s going to be a great one—definitely check it out.

At Productside, we’re really here to serve the needs of product professionals everywhere. If you’re interested in expert help for your team, please contact us. You’ll find additional resources on our website and in the follow-up email.

A big thank you to Ken for this amazing presentation. I learn something from you every single time.

Ken Feehan | 01:30:15–01:31:10
Thank you, Rina. Thank you, Michelle, and thank you everyone for joining. Become a problem-side product manager, and let’s get you promoted.