The Product Velocity Stack - How the Best Companies Move Faster
Speed (usually) wins, but how do you move faster? Breaking down the product velocity stack with lessons from Cash App, Rippling, Ramp, and more.
👋 Happy Sunday, friends!
As you read this, we’re currently wrapping up our first family roadtrip - driving back from Oklahoma to Colorado. It’s the first time our boys have been in the car for longer than two hours…ever. Please send coffee (or maybe a beer?) and words of encouragement.
Hope you’re enjoying your summer thus far. We’re having a blast! 🏄🏽
Have an awesome week ahead,
Jeremey
Thanks for reading another edition of Strategy Meets World – a weekly deep dive into building products that serve customers and the business. If you’re new, check out the intro post and subscribe to get future issues in your inbox.
📬 Either way, email me at jeremeylduvall@gmail.com and tell me what you’re building. I’d love to hear it.
If there’s one truism in startups, it’s around speed wins. Or, borrowing my new favorite phrase from Varun Parmar, CPO of Miro, “You want to be the first one to hit the brick wall.”
The benefits of speed are relatively straightforward. If you can ship quicker, you can learn, iterate, and deliver value far ahead of your competitor. You build a lead in the industry (or close a gap) and potentially win the market as a result.
shared a very tangible example in his (fantastic) breakdown of Cash app. Despite Venmo getting a significant head start, Cash app was able to close the gap in the market with faster execution.
The natural next question then is how exactly do you increase speed?
Google this and you’ll find a grab bag of tweets, blog posts, and conference talks. Protect deep work time. More regular syncs. Fewer syncs. Better alignment. Psychological safety. Ruthless prioritization. The list goes on.
How do you know where to start? I’ll pitch an idea. Start with culture, layer on frameworks, and end with tactics.
The key idea here is that product velocity is a stacked problem. Here’s how I view the individual layers:
Culture - The natural tendencies of your organization.
Frameworks - The foundational principles you rely on.
Tools and Tactics - The day-to-day stuff allowing you to get work done.
Why make this differentiation? When you’re solving a speed problem, it’s easiest to reach for tactics, but those are only effective if you’ve solved the culture and framework layers as well.
Start With Culture
Ramp is one of the fastest growing startups of all-time, hitting $100 million in run rate in two years. They’ve accomplished so much yet if you visit days.ramp.com, you’ll see a number that’s continuously counting up…in decimals.
Day 1572.549… of Ramp. Not, “Year 5.”
This is a small example of a broader piece - company culture is the starting point for moving quickly. If you don’t start with culture, you’ll attempt to use tactics on a week foundation.
I think of culture as the norms and values of a company. It’s reinforced day after day by everyone, and because it’s often invisible or unspoken, it can be tricky to pin down and discuss. But, it represents the default. Great things can come from changing the default.
As a quick example, at Automattic, if I wanted to schedule a meeting with you, it was customary to Slack you to schedule a time (calendars were private). We’d have inevitable back and forth before settling on something. When I arrived at Zapier, people would just schedule meetings directly on my calendar because it was shared. It was a culture shift that took some time to get used to, but everything sped up a tiny bit.
Companies move faster when leaders establish a culture that values speed.
At Ramp, our culture is velocity. It shapes every process and team ritual. It’s how we develop our people. It’s our solution to nearly every problem. - Geoff Charles, VP of Product at Ramp
Progressing to Frameworks
Now, we start to move into more familiar territory. Frameworks is where we can start discussing agile methodologies, planning cycles, team structure, etc. But, the frameworks rest on a culture that prioritizes speed.
Frameworks breakdown into several pieces that all build on one another.
1. Planning and Shaping
How do you decide what to work on and when to prioritize one thing against another? How often do you come together to align your team around the strategy and shape the work ahead? Who is involved?
No one likes planning cycles, but they’re necessary to move in lockstep as an organization. Teams vary between monthly/quarterly/semi-annual/annual planning cycles. Here’s my rule of thumb:
Shorter planning cycles are helpful when you’re exploring new bets and testing assumptions. I call this the “I wonder…” stage. Projects are smaller, and we need to adjust course frequently.
Longer planning cycles are helpful when there are fewer unknowns. We’re relatively certain about what we’re building and why. We’re ready to make a sizable bet. I’ve referred to this as “I’m pretty sure…” type bets.
In addition to cycle length, two additional ideas I try to keep in mind:
Shrink the distance wherever possible. There’s no shortage of posts on MVPs. If you’re going to read one, read this one. Here’s the central question to ask:
What is the cheapest and fastest way we can start learning?
This doesn’t always make sense. If you’re an established player in a defined market with well-known expectations of how a product should work, an MVP approach might not make sense. These are the commodities within your product. You have to get them right, and you should look for ways to differentiate. But, you have a template of what to build.
MVPs make the most sense when you’re:
Validating a new theory
Playing in a new market
Testing out a new behavior for customers
If one or more of the above are true, it makes sense to shrink the distance.
Rethink constraints. One of the main differentiators for Cash App was instant transfer. Across the entire product, if you receive money, it’s available instantly for you to spend.
…there still in the world today are like lots of businesses and processes that are like asynchronous, but not for any reason other than, that's just the way the world is.- Ayo Omojola talking about what he learned from building Cash App.
I imagine there are dozens of good reasons why other companies like Venmo didn’t originally do this. Fraud is a big one. This illustrates the importance of rethinking constraints and operating from first principles. If you’re building a peer-to-peer payment platform, you could look around and just assume there’s a standard hold time before funds become available. This is how imagined constraints carry on across products and industries to slow down or stop work; no one ever stops to think if the constraint is real.
Instead, start from first principles and then “go to the ground” to really understand what’s in your way.
2. Team Structure
How do you divide the work amongst teams and get things done?
Minimize the number of times a team will need to meet with or wait for another team. - via Lenny in “What Seven Years at Airbnb Taught Me About Building a Business”
Self-contained teams that have full control over what they’re working on move faster. Period. As soon as a team has to wait for someone else, everything slows down. Two distinct pieces to team structure - size and makeup.
For team size, take Amazon’s well-known pizza rule or Basecamp’s “three’s company”:
Nearly all product work at Basecamp is done by teams of three people…We don’t throw more people at the problem, we chop problems down until they can be carried across the finish line by teams of three…Big teams make things worse all the time by applying too much force to things that only need to be lightly finessed. - It Doesn’t Have to be Crazy at Work
The core principle is the same - as the team grows in size past a certain point, everything becomes more difficult. Decision making is slower. Meetings take longer. Communication is more cumbersome.
Secondly, consider the team makeup. If you have mix designers, engineers, product managers, and data-minded folks all on the same team, it’s an autonomous unit that can tackle any problem ahead. Each function has an equal representative that can help shape the solution and contribute. Teams can shift as project needs evolve.
Again, I’m learning a ton from Ramp specifically in this area.
3. Decision Making
When an issue arises or a decision needs to be made, how is it handled?
Nothing slows a team down as much as the phrase “Let’s discuss sync; I scheduled a Zoom call for Thursday.”
Why can’t we make decisions faster and unblock everyone? Because decisions are inherently uncomfortable! It’s often unclear who should make the decision, and there’s a perceived real risk in making the wrong decision. The end result is we push off decisions to a later date and try to make them by committee.
In order to move faster, we have to get more comfortable with letting a single person make a decision.
A few nuances on this:
Stakes are obviously important. Bezos’ famous one-way vs. two-way door analogy is the best framework for keeping in mind.
Trust leaders and experts. HR tooling startup, Rippling has a core value - Leaders are right, a lot. Scott Belsky talks about the importance of having a “golden gut.” Default to going with the expert; then, measure their decision-making ability over time. Are they usually right?
End With Tactics
Finally, we’ve arrived at tactics - the top of the stack. This is the easiest place to start because tactics are easy. It’s simple to switch to a new tool or try out a new meeting structure. It’s not as easy to change your culture or fully embrace a framework.
Tactics abound and could be a full post itself. Instead of doing that I’ll share this community-driven post from
:
Over to You
I’ve been noodling on this idea of product velocity as a stacked problem for some time. Does it make sense? What am I missing? I’d love to hear your thoughts!
If you got anything out of this edition, it would mean the world to me if you forwarded it to a friend or shared it on one of your social networks.
Better yet, reach out and tell me what you enjoyed. I’m always here at jeremeylduvall@gmail.com.
See you next week,