Great products come from great product teams—not from frameworks. Using the right product framework can help guide a team’s work. But the product will be only as good as the people behind it.
Product Frameworks Can Become a Crutch
A few years ago, marketing author Seth Godin appeared on a business podcast. The host wanted to talk about Godin’s legendary blog, where he has published a post every day for decades. When the host asked him to describe his process for sticking to such an impressive schedule, Godin refused. I’ll paraphrase his response.
The process I use to write a blog every day is irrelevant to everybody but me. The danger in telling it to you is that many people are looking for a shortcut or easy answer to becoming more productive. If they’re listening to us now, they might be hoping they’ll find it in a list of steps. They won’t. My process is just that, a process. It’s not the work itself.
Don’t get me wrong. As a product leader, I encourage my teams to use whichever product frameworks they find helpful. ProductPlan has written about frameworks to help with product prioritization, frameworks to develop an effective product strategy, and some of our favorites for UX designers, including Google’s HEART framework.
But as Seth Godin said, you need to avoid the trap of confusing your framework with the work itself. For product teams, that work involves all of the familiar roles product managers and product leaders are responsible for, including:
- Building and leading a great product team
- Getting to know your market and users
- Identifying market problems worth solving
- Earning the trust of your prospects and customers
- Directing your team’s energy toward the right strategic goals
That bullet list could serve as your product framework. But you will need to execute each of those steps successfully, and the framework can’t magically make that happen.
How Useful Are Product Frameworks?
To answer this question, I’ll ask one of my own: Can your clothes lead to success?
You know Steve Jobs wore identical outfits to work every day: the black turtleneck, the blue jeans, the sneakers. I’m guessing you also know why. It reduced the number of things he had to think about each morning, giving him more mental energy in the day for Apple.
Thousands of entrepreneurs and executives followed that Steve Jobs framework. Today, we have thousands of business leaders wearing the same thing to work every day. But do we have thousands of more Apple-caliber companies out there as a result? Of course not.
Which is a good lead-in to discussing what frameworks can and cannot do for product leaders and their teams.
1. Product frameworks free up time and creative energy.
Think of all the steps along your journey, from developing a new product concept to get that product into your customers’ hands.
Many of those steps will involve creative thinking, strategic planning, and effective teamwork. To get the most from your team on those steps, you’ll want them to have as much focus and mental energy as possible.
Then there are the less-creative steps: the checklists, the meetings, the review processes. One way to free up more energy and time for the project’s creative aspects is to make these steps as routine and standardized as you can.
Think about it this way. If your team’s sprint sessions run each time differently, team members will have to spend more time thinking about how they’ll handle the various ways the next meeting might go. They’ll also spend more time during each session discussing the logistics of the meeting itself, leaving less time to focus on the tasks they need to work on in the next sprint.
The good news is that you can use frameworks to take your team’s guesswork and additional mental energy out of the project’s routine stages.
For example, you can create frameworks to:
- Standardize your team’s sprint, retrospectives, and other meetings
- Give your team the right tools to complete their work efficiently. The right tool meant they don’t spend mental cycles thinking through how to manage those aspects of the job
- Create a standardized signoff process. A process ensures your team knows exactly when and by whom they’ll need their work approved before they can consider it done
Most teams get this wrong, I believe, is thinking the right framework will improve their work’s quality or creativity.
In reality, it works more like this: You use frameworks to move the logistical tasks to the background, so you can create more space and focus for the creative work. But the quality of that work will depend on your team’s talent and effort, not on the framework you’re using.
You can put on a turtleneck and jeans, walk into your office, and brainstorm with your team. But if you want to develop a product as ingenious and disruptive as the iPhone, then you’ll also need to walk in with a Steve Jobs brain—and have a team as brilliant as his at Apple.
2. Product frameworks can help a team avoid skipping an important step.
Use frameworks to help your team move the routine aspects of their work into the background. We can call this the turtleneck effect. By increasing standardization, you might find their newfound energy leads to some great ideas and increased enthusiasm.
That’s great. But you need to be careful. If your team is so excited about an idea for a new feature and so energized to start building it, you could neglect an important step, such as your normal vetting process.
You might be convinced the idea is viable, even groundbreaking. But before you commit resources to it, you’ll need to step back and take a few important steps. Maybe part of your process is to perform a cost-benefit analysis of any new functionality or ask your sales team if they’ve heard interest in such a feature from prospects or customers.
You never want a framework to constrain your team’s creativity or to slow their work. But you also don’t want your process to be ad hoc, so driven by intuition, that you’re creating products using completely different processes every time. It would help if you constructed some guardrails to keep from going down the wrong path.
Build a very loose framework that includes at least a few basic steps—such as “Let’s test this idea with our persona before building it.”
3. Product frameworks can prevent ad-hoc requests from pulling the team off-track.
Using a product framework—and, more important, making sure your organization knows you’re using it—can also help your team deal more effectively with the never-ending stream of requests that can derail their progress.
Let’s says your team has no fixed stages or guidelines during the development process. You improvise your approach from scratch for every new product or even for every update to an existing product. What’s to keep a sales rep or executive from demanding your team stop everything from building something they want to prioritize?
Without a process that you can point to, you will have to negotiate these requests every time. And in many cases—particularly with an executive—you’ll lose. Worse, every time they have to shift gears and refocus on a different creative project, your team risks not fully re-engaging in the work they were doing on your product.
Using a framework that allows you to stop accepting new ideas or requests after a certain stage will help you protect your product team from these disruptions and frustrations. It will let them stay focused creatively on the same initiative throughout the development process. That will improve the chances your product will be a success.
Pro tip: make your own product framework mashup.
Bruce Lee famously developed a unique martial arts style by using moves and strategies from many different fighting styles to build his own. Essentially, Lee created a martial arts mashup. You can do the same with your team’s framework for building products.
A product framework exists to serve you, not the other way around. If you can’t find a framework that suits your team’s unique traits and needs, design your own. Or do what Bruce Lee did, and poach just what works for you from several existing frameworks.
How Should Product Leaders Guide Their Teams?
Working with product teams all over the world as part of my job with ProductPlan, I often hear product managers explain that they use a framework—Jobs to Be Done, the Scaled Agile Framework, SWOT Analysis, etc.—because their Vice President of Product or CPO insists on it.
I understand a product leader wanting to standardize how their teams build products. If every team uses an impromptu strategy every time, it can be challenging for the company’s product executive to gauge each team’s progress along the way.
But as a product leader myself, I can tell you from experience that adhering to a product framework can become a crutch. A team can fall into the trap of devoting their energy to checking all the boxes on their framework—which takes the focus away from making sure they’re building a product that will make their customers’ lives better.
My take on frameworks is that teams should treat them as suggestions and tips—not rules. Product leaders should encourage their teams to use frameworks only if they serve the team’s needs.
So, if they’re not going to insist on a product framework to manage their teams’ process step by step, how would I suggest product leaders guide their teams? They should focus on a few broad strategic goals:
1. Hire the right product team.
I’ve written some tips on the ProductPlan blog about knowing you’re hiring a good product team member so that I won’t rehash those details here.
But I do want to point out that building great products starts with building a great product team. You can also think of it this way: even with an excellent product framework, a poor or inexperienced team will likely develop a disappointing product.
2. Give the team the tools they need.
Once you’ve assembled a team of smart, skilled, and enthusiastic people, your next task as a product leader will be to equip them with the tools to succeed in their roles.
This might include a project management platform, a product roadmap app, data analytics software—whatever tools your product team needs to accomplish the strategic goals they are attempting to achieve.
One of these tools could even be a product framework. What’s important to keep in mind, though, is that the decision to use a framework—like the decision to use other tools—should from your product team. These should not be top-down decisions the product leader makes.
3. Establish success metrics to guide the team.
You’ve built a strong team and equipped them with tools that will give them the best chances for success with the products they create. Now you’ll want to tell your team exactly how you will measure their product’s success.
This is a key reason the right tools play such an important role in your product team’s work. If you choose user-session length as the success metric for your SaaS app, your team will need the analytics tools to monitor that data and learn how and where they can improve the app to increase session time.
If you make revenue your main gauge of success, you’ll want to make it easy for the team to view every initiative on their roadmap through a lens of its revenue potential. In that case, you’ll want a web-based roadmap app that makes it easy to connect themes and epics to strategic goals.
But it’s also important to remember that, just as no product framework can guarantee you a better product, the tools you buy for your product team won’t be able to do the creative work for them, either. When they open it for the first time, even the best roadmap software on the market will present your team with a blank screen.
