Why You Need to Focus on More Than Speed to Get Results

If you’re feeling burnt out by your team’s lack of progress, you’re not alone. We know from our own experience how frustrating it can be to feel stuck in one of two worlds:

  • Struggling to gain speed with slow decision making or productivity
  • Trying to stay focused when everything is a priority

Whether you experience one or both of these issues, they can block you and your team from high performance.

While identifying the source of friction is important, it’s only half the battle. Knowing what to do about it and how to get started are key to accelerating high performance in your team.

From experience building and running teams at LinkedIn, Degreed, and Sprintwell, I’ve made plenty of mistakes on my road to finding patterns that work. To help you understand the best way to get comprehensive results, I’ll cover:

  • The negative practices that hold teams back from success
  • What you need to focus on instead to get results
  • What steps you can take to make meaningful progress
  • How to get started now

What’s Blocking You from High Performance?

The challenges listed above are frustrating, but they are not the real problems. Slow decision making, burnout, and competing priorities are the symptoms. What really blocks teams from high performance is either:

  • Lack of alignment
  • Lack of speed

Lack of alignment comes from people issues (this is the most common), an incoherent strategy, or a strategy that has not been committed to and written down. Usually, this becomes evident when team members do not know what to align on or someone goes against the grain.

Lack of speed comes from poor habits and systems, lack of skills, lack of empowerment, and lack of motivation or engagement.

But when teams get this right (alignment + speed), their progress is fast, meaningful, and focused.

We call this team velocity, and it’s essential to high performance.

Side note: Team velocity is different than velocity in scrum. Velocity in scrum is a measure of the amount of work a team is capable of completing. It’s usually measured in story points.

Velocity in scrum can be helpful in providing a visual for teams as they think about how much work to commit to and if they are improving throughput as a team. But this can also be destructive as it’s easy to manipulate points and focus on output over outcome.

This highlights two ways we see teams fail to achieve velocity—focusing on speed and outputs as the only indicators of progress.

Why Team Velocity is More Important than Speed

Business team velocity is about the real progress your team makes.

Velocity = Speed + Focused Direction

Shout out to Shane Parrish for the idea of this way to visualize speed vs velocity

It’s about delivering value and impact, not just output.

When a team’s performance is measured by speed or outputs (or both), they rarely get the end result they want. This is because neither one delivers value by itself. You can go fast around a track but make zero progress. You can ship plenty of features for your product, but not deliver anything of value.

Yet teams need to have speed and focused direction.

A team making a high impact on the business has high velocity. A team not making any progress (or worse, creating additional rework for other teams) is operating with low velocity.

And while struggling to move quickly is certainly a serious issue for many teams, we’ve found that lacking focused direction is where most teams struggle when it comes to high performance.

Do you know your team’s velocity? Take our free quiz →

Aligning your team on a focused direction

As Shane Parrish articulates so well about individuals, direction has a lot to do with what you say ‘no’ to. A good strategy is as much about what a team won’t do as what they will do.

Always saying ‘yes’ is the path to mediocrity. 

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things.”

Steve Jobs

This is what makes alignment on your strategy so powerful (and necessary).

It gives you the clarity you need to make decisions quickly and cut through the noise of tasks and projects competing for your attention.

Yet even once you’ve crafted a focused strategy, it’s easy to assume your whole team is aligned when they aren’t. And even after you have gotten initial alignment, you have to work really hard to stay aligned.

When I worked at LinkedIn, the CEO (Jeff Weiner) had a practice that worked magic for keeping teams aligned.

Every two weeks we had a company all-hands meeting. I usually attended in-person, but everyone around the world could join by video. Without fail, he would cover the same points each week:

  • People
  • Product
  • Monetization

He was religiously consistent about touching on these priorities, usually sharing the same metrics week over week. Because I was involved in upskilling leaders on the people development team, I heard Jeff train dozens of times about management lessons he’d learned.

One of my favorites was that by the time you are sick of saying something, your followers are just beginning to understand.

“As organizations mature, the job of any senior executive is about coaching and strategy.”

Jeff Weiner

Getting aligned and staying aligned are the main jobs of a leader.

In the same way, being married doesn’t automatically mean you always love each other, so being aligned with your team at one point doesn’t guarantee perpetual alignment. With relationships, you need to invest time and energy to stay in love. Lasting love isn’t a result of happenstance.

Likewise, strategic alignment doesn’t just happen. You have to invest time and energy in re-clarifying and re-communicating often.

Here are four practices we use in our Strategy Sprints to help our clients find and keep alignment.

1. Setting up shared norms

Any experienced sprint facilitator understands the power of shared norms.

A sprint is like a game. It’s a step out of your normal day-to-day activities and environment. Setting up clear ground rules for how the team will interact is a must-have for getting the results you want.

These include decisions about who acts in what role (decider, facilitator, team member) as well as behavior during the day. Some of our norms for sprints include:

  1. No distracting technology
  2. Give constructive feedback using “I like …, I wish …, I wonder.”
  3. No silent detractors
  4. No armchair sprinters

2. Setting aside time

When we work with teams, we often hear someone say, “Wow, I can’t believe we haven’t taken time to talk about these things.” It’s easy to get caught in the daily work that consumes your attention. Pulling up to talk about important but non-urgent things is hard.

It requires intentionally setting aside time to discuss what’s going well, what desired outcomes matter most to your team, problems that are most pressing, or what principles you believe should guide the team.

This is one reason for doing a burst of focused activity in a sprint is beneficial. Sprints give you permission to take a step back and answer these questions. They allow you to decide on a focused direction and get everyone aligned.

3. Creating space for dialogue

Conversation is important. It fosters shared understanding and encourages all members to contribute.

But it’s easy to only allow for monologue.

Monologue happens when you rely on robust documentation and don’t have safe forums for discussion. When you allow the loudest people in the room to dominate the conversation. And when decisions are made by those at the top with little or no input from those on the front lines.

Alternatively, sprints are sanctuaries for true dialogue. And I’m not talking about endless group discussion here. Ironically, the constraints during sprints around who talks and when actually encourages richer dialogue.

This is similar to the forcing function of Amazon’s 6-pager approach to meetings. Taking time to write a document before meetings and then taking time to read it at the beginning of meetings makes for richer meetings.

4. Encouraging “Both + And” thinking, not “Either + Or”

All too often we think of a decision as a dichotomy. You either have to choose one or the other. If you’re right, that means I have to be wrong. While this does describe some situations, far more often we can use Both + And thinking.

Instead of saying “No” or “But,” you add to what’s good about what someone has said. Example: I like what you’re saying, and I think we can make it better!

These practices give you space (time + environment) to align. Too often we are rushed, do not include the right people in a productive way, and cut down input that harms both the quality of the work and the motivation of the team.

Speed still matters

With all this said on the importance of focused direction, speed still matters.

Hiten Shah missed a billion-dollar opportunity because, after initial success with KISSmetrics, they moved too slowly.

Speed really does matter.

“You can’t just capture the market once and expect to keep it. You have to do it over and over again and faster than everyone else if you want to keep distance from competitors coming up behind you and disrupting you. That’s how you get ahead of the market.”

Hiten Shah

When you sprint (whether a 4-day design sprint, a 3-hour brand sprint, a 2-day strategy sprint, or a weekly agile cadence), speed matters.

But we humans aren’t naturally very time aware. This explains why one UC Irvine study found that it took an average of 23 minutes to return to a task when you get distracted. Setting a timer and having a facilitator help.

Setting a timer

Time-boxing is one way we encourage speed.

We will naturally take an allotted time and fill it with work. That’s why when given an hour meeting, it’s typical to take the full hour. A good way to speed up work is to break it up into smaller chunks and time-box getting those chunks done.

When I need to go fast on personal projects, I use the Pomodoro technique. It’s one of my favorites for personal productivity. If you aren’t familiar, I encourage you to learn about it. You pick one task, set a timer for 25 minutes, and focus on that task. When the timer rings, you get a 5-minute break. Then you repeat. Take a longer break after four Pomodoros.

A sprint is similar. You break tasks down and time-box each one. It’s amazing what you can do with a series of 15-60 minute activities. The time-boxed nature keeps everyone mindful about the clock and discourages irrelevant tangents. It helps create the urgency you want.

To help keep a group aligned on time, we use a time-timer in sprints. 

Designating a Facilitator

A facilitator helps a group move quickly. This is one way we work with companies—through facilitating sprints. Product management done well is a lot of facilitation. PMs keep track of the necessary moving parts, help everyone know where everything is at, and encourage people to participate or pipe down at the right times in the product development process.

One way to think about this role is that they are the driver. It doesn’t mean they are calling all the shots, but they are responsible for forward movement. They have their hands on the wheel.

Having a single, identified driver is a critical element of speed. Group driving usually ends in a mess and happens often when roles are not well defined.

How to Increase Your Team’s Velocity 

Here are some practical steps you can take to increase your team velocity immediately.

Take our free Velocity Quiz first →

Identify sources of friction

When you’re feeling burnt out and frustrated, it can be difficult to identify exactly what’s causing the most trouble.

Set aside time to think through your team’s speed and direction. Where are your biggest challenges? What have you tried to fix it already?

If you’re not sure where to begin (or don’t have enough downtime because you’re too busy putting out fires!🔥), try taking our free Velocity Quiz. It’s an effective tool for quickly identifying blockers, and we send you a custom report when you’re done.

Get alignment on what matters most

We’ve already laid out why alignment is so important for your team. A quick way to get started and check the alignment in your team is to go to 5 different front-line employees. Ask them to articulate their understanding of the current strategy.

“Why are we doing this project?”
“Why does this team exist?”
“What are we trying to accomplish?”

The answers are a quick but important data point to show you if you are aligned. If the answers are different (which they all too often are), you need to create and evangelize your strategy better.

We run 2-day strategy sprints to help executive teams align on strategy. They walk out with a clear, one-page living document that guides their teams. This strategic roadmap is a communication tool you need to use at every team meeting. Make it visible in a place that every employee can find in under 30 seconds. 

Know that agile is about mindset + mechanics

Most botched agile implementations fail because teams adopt the mechanics of scrum without understanding the mindset of agile. This happens because teams lack experience using agile and/or the company culture is at odds with agile values.

Read through the survey results Agile Alliance gathered about failed implementations.

Leaders need to realize that agile is going to be more of a change for them (especially when it comes to mindset) than it is for their teams.

If you haven’t read the agile manifesto, that’s a good place to start. It’s also helpful to talk to those who have built and run successful agile teams—not just as coaches but as product leaders who have shipped successful products. 


You’ll know you have velocity when your team can clearly answer questions such as:

  • Which priorities drive the most value for the business?
  • What results are we measuring to positively reinforce our goals?
  • How can I make the biggest impact today?

Teams with velocity don’t just create more impact, they are fun to work on. High-velocity teams happen when each employee is closer to flow.

If you’re interested in learning more about how you can become a high-velocity team, I strongly recommend taking our Velocity Quiz.

After identifying key points of friction for your team, we will send you a customized report with action steps you can start taking today. We will also send you the frameworks and tools that we use for ourselves and clients to unlock higher performance and results.

Did this spark ideas and questions for you? I’d love to hear about them. Reach out to me anytime at ryan@sprintwell.com.

The Best Way to Build an Effective Product Roadmap

When working with clients, one topic that comes up frequently is product roadmaps. As a product manager at LinkedIn and director of product at Degreed, I kept the best practices and tips based on what worked for me and the hard lessons I learned.

But people rarely ask, “How do I build a product roadmap?”

Instead I hear questions like:

  • How do I move this project forward?
  • How do I get everyone on the same page?
  • How do we get the team moving quickly?

The answers to these questions start with building an effective product roadmap.

Why You Need a Product Roadmap

Before we go into details on how to build an effective roadmap, let’s start with why you need one. 

Done well, a solid product roadmap helps you focus on what is most important. This starts with customer obsession.

“Product roadmaps should come from this idea that you’re actually obsessed with the customer, that you’re looking to solve the problems that your product is supposed to solve for them in a way that’s better than any other business or product or solution or alternative in the market.”

Hiten Shah

This is where product managers come in.

As you focus on the customer, what problem you solve for them, what pain you alleviate, you need to bring others along.

Product managers balance relationships with executives, their team, customers, and more. They are asked to lead, make decisions, and communicate across teams.

With this environment, a product roadmap achieves three key results for you and your organization:

  • Simplicity
  • Clarity
  • Current information

ProdPad describes a good product roadmap as “visual, clear and accessible enough for everyone involved to understand.”

This is critical because of the complex nature of products. Products have many teams involved, a high degree of uncertainty, and the potential for high costs. Communicating simply and clearly in this environment is a must.

Kris Gale, VP of Engineering at Yammer, wrote about the high cost of complexity and its challenges. 

“Among the most dangerously unconsidered costs is what I’ve been calling complexity cost. Complexity cost is the debt you accrue by complicating features or technology in order to solve problems.”

This is why the best product roadmaps have two key characteristics.

They are used as strategic communication documents.They help teams make decisions about what they will and won’t do sooner (before committing to costly solutions).

Second, they are living. This means they are updated often to reflect a current state of the product direction. It also means everyone who views the roadmap understands it is subject to change.

A living roadmap used as a strategic communication tool enables your team to stay aligned and make better decisions.

Unfortunately many roadmaps are too detailed, confusing, or outdated. They function as tactical release plans, and teams get lost.

I like what Melissa Perri has to say on product strategy

“Most companies fall into the trap of thinking about Product Strategy as a plan to build certain features and capabilities… The problem is that when we treat a product strategy like a plan, it will almost always fail.”

A product strategy that is only a release plan will fail.

To avoid this, here’s how to make a clear, concise roadmap that guides you and your team effectively.

What Every Product Roadmap Needs

So how do you actually build a roadmap that is clear, simple, and effective? I teach managers (yes, this goes beyond just product managers) they only need three sections: why, what, and how.

Download Our Free Product Roadmap Template

Section 1: Why

This section answers the question, “Why are we building this product?” This is the big vision, the mission, and/or the purpose (those are different things, to be discussed in a future article).

You want to find a balance between being very aspirational (e.g. solving world hunger) and overly tactical (e.g. “The CEO told us to do this”).

Unfortunately, many people skip this step, or lose sight of it. They include so many details that everyone forgets why they’re making it. I encourage teams to simplify this into a single customer-focused sentence, and then add some context if needed.

A 3×3 walkthrough is one approach we advocate. 

This one sentence is powerful. Everyone can understand it, buy into it, and talk about it in a way that is clear and compelling. 

Section 2: What

Product roadmaps are outcome-driven. Backlogs and release plans are output-driven.

The “what” section of your roadmap answers questions such as, “What outcomes do we hope to drive because of this product?” and “What do we hope changes because of this?”

These are the business objectives that your product will help accomplish.
I recommend including both quantitative and qualitative data to inform this section. For example:

  • What do you want users to do?
  • What do you want users to feel?
  • What do you want them to think?
  • What do you want them to say?

When defining “what,” most people focus on outputs (or features) way too fast. Instead, define the real business value you want your product to drive. This allows your teams to understand the strategy more clearly and better involves partner teams like sales and marketing in your product’s long term success.

Section 3: How

The last section is how, which breaks down into themes and timelines.

I have found the best number of themes is 4-6. These categories simplify the different pieces involved and help your team understand them. They also help guide your priorities and backlog.

Examples of themes can include:

  • search
  • browse
  • email notifications
  • mobile app
  • landing page
  • onboarding
  • payment
  • database
  • settings
  • tech infrastructure

Once you have your themes, you want to decide on a high-level timeline. Three categories I recommend starting with include current, near term, and long term.

While months or quarters seem ideal, they can trap you in commitments to release that you aren’t ready to make. It is better to use more generic terms and talk through the current desired timeline—with the caveat that timing is subject to change. This is a balancing act that depends on your needs, company culture, and other factors.

As an example, if “search” is a theme and our product doesn’t have this functionality, we could break the timeline down like this:

  • Current goal: Add basic search -or- Enable users to search articles
  • Near term goal: Enable users with basic filtering
  • Long term goal: Enable advanced filtering

This helps all teams know which features are coming at the highest level and when.

For example, when your salespeople talk with customers, or support teams check in with developers, this simplified timeline becomes invaluable.

Note: A disclaimer at the bottom of this section is critical, so that those consuming and using the roadmap realize this isn’t set in stone—it reflects the current direction of the team. This is also why current, near term, long term are good timeline categories, rather than exact dates or quarters. It helps communicate the ever-adjusting nature of the themes and timelines.

Download Our Free Product Roadmap Template

Why this Model is Effective

As mentioned above, some main challenges with products are:

  • complexity
  • uncertainty
  • cost

It’s easy to jump to a solution too soon or overwhelm people with too much information. But building a product roadmap is more than categorizing information.

The model we’ve laid out for you also improves communication, sets clear expectations, and enhances productivity.

People from all teams can wrap their heads around the product. The summaries make it easy to digest. Regular updates keep it current. All teams and executives have clear expectations about the general timeline. Developers and designers know what is expected of them and can identify which pieces are missing.

With a visible strategy, it can be questioned by everyone in the process (executives, designers, developers, partner teams) and improved from the ensuing conversation.

And most importantly, using a product roadmap as a strategic tool empowers your team to become truly agile (in mindset and mechanics). People can ask critical questions, shift their focus, and make better decisions on where to spend their time.

3 Mistakes to Avoid

With all that said, knowing what not to do is just as important as knowing what to do. Here are the three most common mistakes I see people make when creating a product roadmap.

Mistake #1: Including too much detail

The main problem here is the product roadmap becomes too complex. There are so many details that teams can’t get through it quickly. Sometimes the roadmap is a 40-page slide deck, and no one can concisely relay the purpose of the product.

This is how I know teams have strayed away from a useful roadmap and created either a run-on sentence of a roadmap or a release plan. They have skipped one of the most important parts—simplicity—and their people can’t digest the information.

This usually happens because teams don’t have the discipline to say no (which causes run-on product docs), or they center their thinking around solutions too early in the process (and end up with a release plan).

Mistake #2: Not defining clear priorities

Another mistake I often see is not including clear priorities. The themes and timelines are not well-defined, and communication is poor. People have unrealistic expectations on what can get delivered and when. 

I often seen vision decks that include dozens of priorities. When asked, “Which of these is most important?” the answer is typically, “Well, they are all important.”

If everything is important, nothing is important.

This is why I recommend a 1-2 page document with clear, useful themes and timelines.

These let everyone know what’s currently being working on and sets expectations for the future.

Mistake #3: Focusing on solutions instead of problems

A final mistake I see often is focusing on solutions instead of problems. We can get married to solutions way too early and focus on shipping features fast.
But teams should always start with problems to solve.

If you become obsessed with a problem vs. a solution, you can say, “Look, I don’t care how we solve it. I just want to solve the problem our users have.” It’s a much better place to be in, and it opens teams up to greater learning and openness to new possibilities.

As a product manager, this also empowers you to defend your product roadmap—your why, what, and how. It enables you to get people excited and bought-in. You can iterate on solving the right problem and create value for customers and the business.

Setting Your Roadmap Up for Success

Even if you follow all the steps above, you still need a strong foundation. A critical component to your product roadmap is the data that informs it.

Without data, it will be hard to make good decisions and get buy-in from everyone involved.

Here are five steps you can take to make sure you have the strongest foundation possible for your product.

1. Talk to Your Users

Product managers are champions for solving valuable problems for real users. It’s not always the easiest or most exciting problem, but it should be the most impactful. People pay for products that solve real problems, so this step is critical.

Design sprints (originally developed at Google Ventures) are one way you can test this up front and avoid wasting time and energy on the wrong problem or solution.

But in order to do this, you must talk to your customers. Learn how they use your product and understand what they want. Join sales and support calls. Keep yourself updated and build a regular habit of learning from them.

It’s easy to get out of this habit when you are busy with meetings and conversations with stakeholders. But fostering these relationships with users on a regular basis is one of the most important responsibilities you have and will serve you well in the long term.

2. Gather Data

Next, consider what data you already have. What information from market research, historical sales data, or customer behavior is available?

As you continue chatting with users, track this information. Gather relevant data, conversations, and other metrics.

Talk with your executives and learn how they make decisions. Get their input and understand their goals, objectives, and insights. Many of them interact with customers every day and have a unique perspective.

Gathering this information will empower you to make critical strategic decisions. You will be equipped with more than your intuition, and you won’t be subject to the opinions and whims of everyone involved.

3. Align Key Stakeholders

Equipped with data, you can start capturing it and reflecting it back to key stakeholders. This allows you start aligning your goals and get buy-in.

For example, after you write down your one-sentence vision for the product, go to the CEO or head of product. Ask them, “Is this accurate?” Share your conversations with customers and why you think you’re building the product. Give additional context, metrics, and what outcomes you hope to drive.

Because you have written it down and gathered data first, it will be easier for them to react. They can offer feedback, ask questions, and have a specific conversation with you. You can identify key areas where you are not yet aligned and address them.

Then, when it’s time to get alignment on the full product roadmap, you have already resolved most concerns. You can confidently say, “Here is the roadmap, and I think we’ve all agreed on it. What questions do you still have?”

But whether or not you use a sprint to get this initial alignment, roadmaps still require ongoing work. It should be adjusted and updated continually—and that requires continually making sure people are aligned.

4. Tie Your Backlog to the Strategic Roadmap

Now that you have articulated why your product exists and aligned your teams on the roadmap, it is important to make sure your backlog reflects this.

There is a lot I could talk about here with how to prioritize your backlog and incorporate user stories. It is a complex process, and everyone has a different ways of doing it.

But one tip that really helps me is this — use the priorities in your roadmap as a guide for your backlog.

For example, breaking down the stories for the current prototype or sprint will be much more helpful than getting into details further down your backlog. 

If you start breaking down the stories you plan on using later, you end up wasting a lot of time and energy. Realistically, when you are ready to address those features, everything will have changed. Your priorities may be different because you will have learned and adjusted through the process.

One solution is to group stories based on your themes. You can then add some sub-themes and plan to break them out later.

This method helps keep me sane, especially when product groups have a backlog that increases from 10 to 20 to 50 to 100 items. I have personally “managed” a backlog with 600 items in it.

But no one can realistically manage that, and it becomes useless.

Tying the backlog to the main priorities in the roadmap helps alleviate this waste and allows for more flexibility.

5. Communicate Well (and Often)

Lastly, your product roadmap will only be successful if you communicate well and often. Agile teams are autonomous, self-organizing, and engaged—meaning they can’t rely on one person to tell everyone else what to do.

So great product roadmaps and product managers enable all teams—including designers and developers—to contribute what they have to the product in the best way. They empower every person involved at detailed levels to understand the vision and make informed decisions.

The simplest way to know if you’ve communicated it well is to ask someone what they think the strategy is. Their response will tell you everything you need to know about how well your team is centered strategy-wise.

Strategy isn’t just what you have written down somewhere. It’s what everyone remembers and uses to make daily decisions. 


In the end, a product roadmap done well enables agile behavior. This is because it’s not a release plan—it’s a strategic communication document.

Knowing how to create a roadmap, you’re ready to get alignment across your organization and empower your team.


Join my monthly newsletter where I share practical links and advice from what I learn about product and parenting. Reach out to me on LinkedIn or twitter and let me know how building roadmaps works for you.


Other great resources you might enjoy:


What is a Brand Sprint? How to Use Brand Sprints to Develop Your Brand

If there’s one thing that’s become clear from years of mentoring at 500 Startups, it’s that your story matters. A lot.

Your story and your brand are what users connect with. It’s the big, giant sign posted outside telling them “this is the place for you.” But maybe even more importantly, it’s your own North Star. Your story reminds you of your mission as a company. It gives you clarity, confidence, and creativity. It’s what compels you to wake up every morning excited to forge ahead. (more…)