Learn / Product Forge / Article
How to implement scrappy product management in your team
Like most things, scrappy product management strategies have their pros and cons. Some product teams embrace them with open arms, while others shoo them out the door faster than you can say “release notes.”
Last updated8 Oct 2021
Ideas vary about what exactly scrappy product management is and how to make it work for different product teams. Not to worry—with the help of Hotjar’s Growth Product Manager, Andrei Beno, we'll tell you:
By the end of this piece, you’ll have a good idea of whether scrappy product management could be the right fit for your PM team, and how to implement it into your team's culture.
What is scrappy product management?
Scrappy product management is a culture among product teams that encourages people to act quickly and decisively. How product teams go about doing this and the effects of this culture are often up to debate.
Scrappy product teams are sometimes viewed as argumentative, unorganized, or solely reactive; but many PMs consider the scrappy culture to be more innovative, lean, and autonomous.
“Being scrappy is all about being resourceful and able to make the most of what you have. It's also what gets you going when the going gets tough, as being scrappy implies finding ways to unblock yourself or your team, find creative solutions, and prioritize progress over process.
“You can get closer to whatever goals you're aiming for even if the path to getting there might not be straightforward or clear from the very beginning.”
3 benefits of a scrappy approach to product management
Scrappy product management has some consistent benefits for PM teams, including:
Innovation and creativity
A determined approach to product management
Being okay with not always knowing exactly what’s going on
Better alignment on the company’s
But let's explore three more benefits in a little more detail:
1. Being bold and moving fast
A scrappy product culture leads to processes that encourage team members to act with speed and grit.
For example, a scrappy product management team fosters a fail-fast culture and eliminates the fear of making mistakes. This encourages people to be bold in what they do, take risks, and act fast.
Scrappy teams are less reliant on organizational processes because of their autonomous nature. A scrappy team can often identify problems independently and map out pathways to solutions without getting stuck in feedback loops.
For example, your product team can carve clearer pathways to business goals by using OKRs, quarterly product planning, and product roadmaps. They know what projects they can independently act on if it will bring them closer to those goals.
Product owners can encourage team members to connect with others who align on common value streams, customer experiences, or shared objectives. Over time, product networks can step away from feedback loops and become more self-sufficient.
3. Responsive product workflows
A scrappy product team can respond to red flags as soon as they appear because you can skip bureaucracy and bottle-neck approvals to get things fixed as quickly as possible.
For example, in a scrappy product team, if a developer spots a website bug they can just squash it—provided they have the tools and know-how.
But in a more formalized devs team, the developer may have too much focus on big roadmap items rather than pesky red flags. They may need to track the bug, seek approval to deal with it, assign it to someone who has time, and then A/B test the fix before fully launching—and before you know it, you’ve lost users.
These benefits resonate with many PMs and are the reason scrappy product management is so widely embraced. However, despite its obvious benefits, scrappy product management still faces some pushback.
Why does scrappy product management face some resistance?
Concerns around scrappy product cultures are valid; any deviation in culture comes with potential pitfalls and challenges. But when you’re moving from a more formalized organizational structure—where things run like clockwork—to a scrappy product culture—where they don't—the risk may not seem worth it.
A few potential negatives of using a scrappy approach include:
Expiring knowledge bases
In a culture where information changes hands so quickly, knowledge bases can become redundant, fast. It can seem unnecessary to update a knowledge base every time something changes, especially if it’s a time-consuming task or there’s not one person responsible for the update.
This leads to disorganized knowledge after sprints or times of great change.
Unnecessary notifications and distractions
As mentioned above, in a scrappy working culture, people rely on other people for knowledge. This means that if your product team uses a communication tool like Slack, someone could be inundated with messages throughout the day, pulling them out of their flow and slowing down overall product development.
Higher chance of reiterations after release
In a scrappy culture, people are encouraged to work fast, and failing is not feared as much as in a traditional culture. (Some may argue that failing is embraced in a scrappy culture.) This is great for getting work done but could lead to multiple redos post-release, which is costly and consumes unnecessary time from your product team.
Stressful, high-demand environments
Scrappy teams emphasize acting quickly, but enforced speed can add pressure to product teams. This pressure can lead to burnout and push-back from certain personality types—it’s not everyone’s cup of tea. These burnouts will soon start to show in your team morale and affect their work, happiness, and general wellbeing.
💡 Pro tip: it’s worth noting that the 'negatives' we mention above are not necessary collateral—they occur depending on how you implement a scrappy product culture, and there are potential solutions, some of which we share later in this article. In short:
Expiring knowledge bases: find owners for different areas of the knowledge base. These people are responsible for updates after moments of change.
Notifications and distractions: limit contact hours and allow team members to toggle their notifications on and off.
Post-release reiterations: efficient QA processes can still help teams release fast, but with greater assurance you’re releasing without errors.
High-demand environments: look after your team, create an open-door policy with managers, and ensure all team members feel safe speaking up about mental health.
Going scrappy doesn’t have to mean completely throwing out old processes and traditional organization. Andrei says, “As a Product Manager, I think there's value in both being scrappy and resourceful, as well as being structured, methodical, and reliant on long-term planning.”
From his experience, it’s easier to be flexible within startups—where teams can work under high ambiguity and find pragmatic solutions to problems—but more difficult at larger companies, which tend to rely on processes and structures due to their size and organizational designs.
In large enterprises, being a hyper-specialized product manager who thinks long-term and focuses on highly scalable approaches is viewed as a lot more important than being scrappy. But Andrei sees virtue in a hybrid approach, saying: “While there's definitely a larger need for being scrappy in a startup environment, I believe all product teams can benefit from adopting a scrappy mindset.”
Here are ten ways you can implement a scrappy mindset into your product team.
10 ways for product teams to adopt a scrappy mindset into their workflow
1. Create squads that share a scrappy mindset
If you want to gradually implement a scrappy culture into your product team—or your entire company—start by creating squads with scrappy mindsets. Being scrappy is sometimes considered more of a mindset than a skill, so select people you know would thrive in this squad environment.
Much like a phased release of a new feature, you can beta test the culture with squads, then get feedback, optimize, and roll out with greater assurance. Andrei has achieved great success by combining people with a scrappy mindset into the right squads:
“With my current squad, we aim to always consider the effort vs. impact ratio of everything we're working on and thinking MVP first,” he says.
For example, Hotjar recently wanted to create a Product Demo feature that would allow visitors to explore the product and its features before signing up.
Creating a dedicated sandbox account is a large project, so the Hotjar team put their scrappy hats on and thought about what the MVP for this feature could look like.
“After a few rounds of ideation, we ended up creating a site with dummy content, created a regular Hotjar account that we integrated with that site, and we had our team go on the site to simulate the type of activity that actual website visitors would do, and enabled all of our users to get access to that account.”
This significantly reduces the amount of time and effort needed to test if a Product Demo has a positive impact on visitor experience, and helps them better understand what Hotjar does and if it's the right fit. “The experiment was successful, so we're now building on top of it.”
This wouldn’t have been possible without the collaboration of scrappy squads. These squads act as a collective knowledge base, act quickly, and eliminate the fear of disorganization that often accompanies scrappiness.
2. Try scrappy user research techniques
Rather than implementing an entirely new culture, start by implementing parts of it into your product strategy to win buy-in from your team. For example, scrappy user research techniques are a great way to showcase how the mindset can benefit product development.
Scrappy user research doesn’t rely on beautiful processes or formalized documentation, which is why it often trumps traditional user research techniques. It gets the job done, and by doing the same within your product team, you’re likely to highlight a few benefits to working in a scrappy way.
The product team at Hotjar tends to adopt a scrappy approach with research. For example, they might put together a Trello board with a Zapier integration that populates the board with the contact details of users that fill in a survey or provide feedback. Once new feedback comes through, different teams can review it, and if it's relevant to any specific team, a calendar invite is sent to the user to book time for a user research session.
Andrei explains a little more on how the product team’s process operates today:
“It's not the most elegant setup. It implies a series of manual steps and is sometimes prone to error, but it gets the job done, and it has enabled our 10+ product teams to start doing user research immediately, instead of waiting for months to have a better-refined setup before getting started.”
3. Run a cost of delay analysis
A cost of delay (CoD) analysis will highlight the amount of revenue your product might lose by delaying work and being slow to implement ideas. Running a CoD analysis can be an easy win if you’re looking to get leadership buy-in for a scrappy product development team.
For example, if you think your current user research methods are taking too long to provide results, it may be worth presenting the cost of delay divided by duration (CD3) to stakeholders to show where a faster, more flexible approach to product management might increase revenue.
4. Run a structured communication strategy
For a scrappy product culture to run efficiently, you’ll need a structured communication strategy. Your team needs time for deep thought and independent work alongside opportunities to collaborate.
Adding structure to your scrappy approach may seem counterintuitive at first, but when you bring structure to communication channels, you give your team members space to work independently without fear of missing something, and you’ll utilize cross-collaboration moments more efficiently.
This also means that communication should be restricted to certain channels for people to do their independent work. For example, you may consider keeping any work-related conversation within your project management tool or specific calendar hours, or allow team members to snooze Slack and other notifications so they can focus.
Consider scheduling team meets in a regular cadence, too—but always review the agenda ahead of time to see if the meeting is really needed, or if you could communicate updates async.
5. Foster a fail-fast culture
A fail-fast culture is critical to a scrappy product team: it encourages your team to learn from mistakes and act quickly when they occur, while also eradicating the fear of failing, and inspiring greater creativity and risk-taking.
For example, Adobe fosters a fail-fast culture by pairing the right technology with creativity, enabling collaboration, highlighting company purpose, and building a supportive company culture.
But keep in mind that knowing what doesn't work is often as important as knowing what does. Here's what Andrei says about his approach to failure at Hotjar:
“My squad runs a lot of experiments. We consider those successful not when they validate our hypotheses but when we get valuable learnings from them.
“The faster we can learn the better, irrespective if we launch something new that did not have the impact we hoped for. We're happy with the experiment’s outcome if we were able to draw some conclusions that can inform our future direction.”
6. Adopt a 'progress over process' mentality
Many companies adopt a specific framework and try to follow it to the letter, only to fail due to a lack of flexibility.
Common examples of this are adopting an OKR framework, the Scrum methodology, or a squad-based organizational structure. There isn't a one-size-fits-all process for every team, and following something that might have worked well for another team doesn't guarantee it will work for yours.
This is when having a 'progress over process' mentality comes into play. Instead of fully adopting a process-heavy framework, consider your objective and try to find ways to get closer to it, even if it's in a more scrappy way.
“For me, progress definitely trumps process,” says Andrei. “I prefer a pragmatic approach to work that implies taking sensible decisions and using my best judgment and common sense.”
7. Stay in touch with your users
It can be all too easy to rely on instinct and quick fixes when it comes to a scrappy culture, but it's important to be customer-centric and put the users' needs first. Scrappy product teams can deliver great work by staying in touch with users.
Here are a few ways for your product team to understand and empathize with your users
Reviewing UX reports and
Regularly reminding your team of your user persona work
Making time to watch
Staying updated with
However you choose to stay in touch with your users, it’s a massive benefit for your product team to continue building with the user in mind while thinking and acting in a fast and scrappy manner.
💡 Pro tip: if you’re conducting user research with Hotjar tools, here are a few ways you can stay in touch with your users and get actionable feedback.
Use Hotjar Surveys and Incoming Feedback widget scores to better understand what your users consider important, in their own words. This helps your product team make decisions that ultimately retain customers.
For example, in Incoming Feedback, a user may indicate that they’re frustrated because the checkout page is blocking them from purchasing. However, only when your team uses Session Recordings can you identify why and how the user is experiencing the blocker—then fix it.
8. Make time to celebrate small
We know by now that scrappy teams act fast, which means once your team has solved one issue, they’re often already knee-deep in the next.
It’s helpful to slow things down from time to time and celebrate small wins. Don’t wait for the end of the quarter to let people know you’ve hit goals or to highlight big achievements.
It's especially important to celebrate small wins to ensure your product team knows their work is valued, which will help retain staff and build team morale.
9. Get rid of the gut
Since scrappy product teams work at such a fast pace, gut instinct could be a negative effect. But if you run regular quantitative and qualitative user testing—using our methods from point 7—you’ll ensure all of your product team members continue to build with the user in mind and release solutions people want, need, and can use.
Your product team can still be efficient and agile when data-minded, and research should not be considered a blocker for new releases. When your product team remains in touch with users and user research with Heatmaps, Session Recordings, Incoming Feedback, and Surveys, every rapid decision you make is still an informed decision.
By continually ’feeding the gut’, you empower your team to make the right decisions quickly—without needing to run tests every time—because you’ll already have a good understanding of the users' needs.
10. Optimize your scrappy processes
Always be on the lookout for other ways to optimize your team culture; it’ll never be perfect. As your company grows, your team changes, your initiatives might pivot, and you’ll need to find ways to keep your scrappy culture lean.
Make time to get team feedback, analyze processes, and try new ways to remain productive while keeping a healthy balance between workloads.
When it comes to optimizing your scrappy product team’s workflow, the best thing is that you’ll already be great at finding rapid solutions. If your team does run into difficulties with this new culture, you’ll be able to quickly identify new ways to overcome hurdles.
Is scrappy product management right for your product team?
There’s no one-size-fits-all solution for a scrappy product team. Find the elements of a scrappy approach that are right for your business and your team members, and be flexible.
To get started, try the methods we’ve suggested in this article. Launch your strategy in segments, test techniques, and get buy-in along the way. Figure out what works best for your team, and if something doesn’t work: fail fast and try again.
Introduce a tool to enable your scrappy product team
Hotjar gives you product experience insights that help your team get the job done, fast.