Imagine this scenario. A team member approaches you excitedly and says, “I just sat in this amazing sales meeting, and I have an idea for a new feature we have to build! You would click here and here, then be able to do this, and it would work like this!” Maybe your coworker is even drawing you a picture while they’re speaking to you.

They finish off by asking, “So when can we have it?!” All the while your eyes are smiling, but you’re thinking, “Sh$t.”

First, take a deep breath. Product thinking is here to help.

Before we jump into the tactics, let’s get on the same page about product thinking. At its core, product thinking is problem-solving. When you apply product thinking, you are putting your users’ needs front and center while progressing from problem to solution. Let’s take a closer look at how you can get your entire team thinking like a product person.

Product thinking will help you know what to build

Start by identifying the problem. Tools, like personas and Jobs To Be Done, can help you define your problem space.

Ask yourself:

• Who is your user?
• What does your user need to do?
• Where is the pain or friction?

Then, explore the opportunities. Consider:

• How might we solve the problem for our user?
• What is the potential impact of solving this problem for users and for our business?
• What’s the risk of not solving this problem?

Last, explore possible solutions. Investigate:

• Which solutions are reasonable for our business?
• What are our constraints?
• How does technology enable us?

Now, back to that teammate from earlier. What’s the best path forward when you’re presented with a fully baked solution?! Take a pause, acknowledge the other person’s interest and enthusiasm, and gently pivot the conversation back to the problem. Here are some ways you can do that.

I like to use a template with my teams. To get started, you can keep it simple with a few, key prompts. For each new idea or solution, ask your coworker to provide the following:

1. What is the problem we’re trying to solve for X user or X persona?
2. “How might we” solve this problem?
3. What does success look like for the user and for our company?

Thinking through these points will help flip from project or solution mode into a product thinking mode. At first, it’s helpful to pair with your teammates and fill in the template together. Once they’re comfortable with the format, you can leave them to do it on their own and then review it together.

Encourage your team to provide supporting evidence from analytics, user feedback, or competitor or market research to support their thinking. Job stories from the JTBD framework are a great alternative to the basic template.

If you want to go into more detail with your stakeholders, you can make use of the 5 Ws and H for a thorough analysis of the problem, opportunity, and solution spaces. This template is best used in a workshop format, where you can brainstorm responses to each question in a group.

Don’t forget — if the person with the idea can’t clearly articulate the problem, research is needed. You could run a day of qualitative research, send out a survey, do an environmental scan of the market or competitors, or dig into your product analytics. Any data that proves that there’s a problem that needs to be solved can be helpful.

Product thinking will help you prioritize

So, once you’ve worked out what to build product thinking can also help you prioritize. I think PMs take a lot of unfair heat about prioritization. It’s common that when prioritization is tough and pressure is high, PMs jump to using frameworks to help put features into order.

But, when PMs have difficulty prioritizing usually it’s because they lack information about company strategy. It’s not because the PM is bad at prioritizing or lacking the right tool. PMs need clear company goals to prioritize successfully.

Let’s take a closer look at how company goals relate to prioritization. Imagine your company’s strategy is made up of vision, goals, metrics, and actions. In a company that’s not particularly product-led, the actions will be handed to you as features that you’re expected to prioritize.

But what does this look like in a product-led company? In a product-led company, the company goals are your starting point for product goals. To develop your product goals, you can also factor in user feedback, internal feedback, and what the broader market is doing.

Once you have product goals in mind, choose metrics that will help you measure progress. Then, the next step is to generate, collect, and thematically cluster ideas. This is the fun part! You can run brainstorming workshops, prototype, talk to users, and employ other creative techniques that will help you go broad.

Ideally, your goals, metrics, and ideas would be informed by research, and the research will help you narrow down your ideas to a shortlist. If your team isn’t quite there yet, that’s OK — it takes some amount of product and process maturity to be able to implement research in a regular way.

Once you’ve clustered and ranked your ideas, you’re ready to break them down into features or shippable increments. And then, after all of that has been sorted, you’re finally ready to prioritize!

Cut yourself some slack — prioritization isn’t easy. You aren’t meant to get handed a list of features and be able to put them into order. Actually, a lot of thoughtful consideration is needed before you can get started.

If you’re handed a list of features and asked to prioritize, it’s your job as the product person to shift the conversation back towards the company goals. Ask, how do these features help us achieve our company or product goals? What does success look like?

I’m confident that if you’re getting the right guidance from your management, you’re not going to need prioritization frameworks. But, I’ll admit that frameworks can be helpful in cases where you want to bring transparency to the how and why behind your decisions. Using a visual format, like a matrix, can help get your whole team involved and bring them on that journey with you.

Here are 2 easy frameworks I recommend:

Impact vs. Effort is the classic prioritization matrix. Impact vs. Unknowns is better for hypothesis-driven development or validation sprints. Use this matrix to know what you should test first versus what to build straight away or not pursue at all.

Story mapping, feature stack ranking, and betting are other good tools for getting stakeholders involved in the prioritization process. If you involve your stakeholders and team members in the process of adding ideas or features to the matrix, it will become really obvious to the whole group where to spend time and focus.

Product thinking will help you keep your team aligned

Lastly, product thinking will help you keep your team aligned. Once you know what problem you’re trying to solve and what order to deliver, how can you communicate that to your team and company? You might be thinking, a roadmap is a great tool for this. Applying a product thinking approach to your roadmap can save you from a lot of headaches!

But first, I’m going to let you in on a little secret. A Gantt chart is for projects, not products. By definition, a Gantt chart is a type of bar chart that illustrates a project schedule! Gantt charts take a ton of effort to maintain, don’t actually provide greater transparency, and probably don’t set your team up for success.

If you’re trying to pivot your team to a more product-led way of working, ditch the Gantt chart, and use a now-next-future format for your roadmap.

This format can be used for features, topics, learning goals, experiments you want to run, or problems you want to validate. It’s great for however your team might be structuring your work.

Additionally, the now-next-future roadmap is super easy to maintain, provides the flexibility for any number of changes or pivots, and will give visibility to your team and the broader company about what they can expect to be delivered.

Items in the Now bucket are well-defined, granular pieces of work that are fully scoped. You have high-fidelity designs, requirements, and everything is prioritized and ready to implement.

Items in the Next bucket are partially defined, designs might be in the prototyping or wireframing phase, and requirements are still being gathered. These topics are loosely prioritized.

Items in the Future bucket are high-level, not scoped in any detail, and are fully flexible with regard to prioritization. This group could be a place where you and your team collect ideas for future consideration.

A small caveat — when you roll this out, your teammates who are used to the Gantt chart roadmaps are immediately going to ask about dates and deadlines. You can politely explain that this roadmap shows the relative priorities of various pieces of work and should not be read as a timeline.

Especially if you’re working in a scaling or large organization, it can be helpful to cross-reference your roadmap with a one-pager providing additional context. Use the Product Canvas as your template, or try this simplified format:

1. What are you building? Describe your feature in words
2. Who is it for? Identify maximum 2 personas or user groups
3. Why did you decide to build this? Provide supporting evidence and a description of the problem you aim to solve
4. When do you expect to deliver? Give relative timeframes, not firm dates
5. How does the feature align with the company goals?

If you’ve conducted research that provided supporting evidence, you can also cross-link it to this page.

Take your documentation one step further by t-shirt sizing the features — this will help manage stakeholders who are craving deadlines. Remember to frame your delivery dates in terms of approximates — never promise exact deadlines! You never know what might happen when you get building.