How to ship 10x faster.
For founders, leaders and PMs who want to supercharge product development
Speed unlocks growth. Achieve more by building faster. Speed is built from insane deadlines, high-pressure execution, motivated teams, visible updates, accountability, detail, and rewards. Built through years of scaling TryHackMe’s product and engineering teams - this is what I’ve learned building a product for 4M users.
Please note, engineering is extremely expensive, so you have to make sure you’re building the right things. Speed can’t come without direction.
Set ridiculously uncomfortable ambitious deadlines
Use your gut and intuition to set a deadline that feels slightly ridiculous. Don’t let overly cautious engineering estimates define the pace - force ambition, and let the team figure out the solutions. An aggressive deadline creates intensity, ruthless prioritisation, and will push the team to do more than they thought was possible. Engineers are experts at building, but not all are experts at setting the pace - and if you let them set the tempo, you’ll most likely get what’s comfortable
Your team (and you) might question why you’re the best person to set a date, and you’ll probably get push back (if it doesn’t raise an eyebrow it might not be ambitious enough). Work expands to fill the time given (Parkinsons Law), shorter deadlines compress it. If you don't set the clock aggressively, you guarantee bloated timelines. You’ll be significantly further along with an ambitious date than without one.
Tips: send the exact deadline in Slack - no “May” or “Q2,”, and don’t let the deadline slip. Its easy to get a few weeks out and move it - but the real push and intensity comes during that final stretch.
Have the right team and people
The entire team needs to have a natural willingness to build - we specifically test for this when hiring and even send candidates an article about our high-performing environment. If this excites a candidate, they’re a good fit; if it doesn’t, they’re not. We also look for previous startup experience - FAANG experience tends to get 10x the credit over finding those who actually love the startup grind.
The best performing teams and people sets the bar for everyone else. There is no excuse for low performers, and you should work to rectify quickly; too often, we delay these decisions. Its unfair on the rest of the team if one person is working hard, and others are not - a low performer will bring down the velocity of the entire team; act fast to protect team momentum.
Tip: measuring engineering performance is a whole other topic, but I can’t recommend GetDX enough.
Pressure must come top down, & bottoms up (the team)
Building product is very cross functional. Everyone’s busy, so set the expectation that if someone needs something, they shouldn’t wait around - ask, push, follow up. They should do whatever it takes to keep moving, and no one should be shy about chasing to get things done. Examples:
Engineering waiting on a decision from product - push and follow up
Product waiting on a decision from stakeholders - push and follow up
Engineering waiting on code reviews from the team - push and follow up
The team should never be waiting around. They should be following up regularly, pushing and challenging others. It doesn’t matter who it is - even SLT - everyone should apply pressure to keep things moving. Instead of thinking, “I’ll get to that next week” or “they’re probably busy” the mindset should be “why don’t you do it today?” and “who else can I go to so I’m not blocked?”
Supercharge your team with AI
We’re in an AI revolution as big as the industrial revolution. If you’re not using AI to build product, you’re already falling behind. It can supercharge ICs' capabilities and productivity. There’s a lot to say on this, but here are a few of my favourite TryHackMe success stories.
Technical Support - Someone from our support team used Cursor to build an admin dashboard, giving her team a direct way to update content instantly - bypassing the usual multi-step handoff to engineering.
Engineering - Using Cursor an engineer (without being asked to) made a page to monitor, update and re-run scheduled tasks, all within just a few hours. This was previously a very manual process, which will save the entire team a lot of time.
Design - Product design used Bolt to make a fully fledged new product experience that we ended up showing clients to help with discovery.
Content - The team developing our lessons uses Bolt to help create fun interactive exercises.
Using AI at work should be a baseline expectation - make sure your teams are using it. I really like how the CEO of Shopify wrote about this.
Get the team motivated
Not only do you need the right team, they all need to be motivated, excited, and believe the deadline is possible. Steve Jobs set ridiculously uncomfortable ambitious deadlines, but convinced the team it was possible, and a term was coined for the way he did it: “The Reality Distortion Field” (RDF)
The RDF mixed charisma, relentless will, and a habit of bending facts to fit the purpose. Strangely, it worked even when you saw it happening, and over time we stopped fighting it, accepting it as a force of nature.
~source
Andy Hertzfield, a key engineer working with Steve on the original Macintosh, talks about the RDF here; getting 24+ months of work done in just 12. He also raised a pirate flag in the office to rally the team around speed and rebellion.
Get the team excited. Everyone on the team is motivated differently, and you should lean into that for each person. Here are a few things I like to do:
Show numbers – remind them how big the impact is by sharing real numbers (e.g this feature will reach 4 million users).
Talk about the work’s impact - connect the project to real outcomes like changing lives or winning market share, and back it up with real proof like customer stories.
Have accountability and milestones
Have just one person held accountable for the delivery of the project. Everyone in the team has a key part to play, but one person should be ultimately responsible. It doesn’t always have to be the PM. For engineering heavy tasks, it can be the EM.
Have milestone breakdowns written up and shared with everyone. Breaking a big project into smaller, frequent deadlines works because teams naturally cram just before something’s due. Shorter deadlines allow you to keep the intensity high.
Intensity will always spike at the end - but great PMs spread that pressure more evenly, so the team isn’t drowning in the final stretch.
Be in the details
Being in the details is a superpower and has so many benefits that many struggle to understand. It allows the team to be close to decision makers, move faster without layers of translation, and build real momentum instead of waiting for approvals. A few other benefits are:
Remove bottlenecks faster - being in the details with your team is a superpower that lets you spot blockers early and clear them before they slow you down
Quicker rounds of feedback - going back and making changes is expensive, by seeing designs, prototypes and being involved in discussions early will speed up development.
There are so many reasons why being in the details is imperative to shipping faster, but its misunderstood as micromanagement. Its not about controlling decisions, but opening up and participating in discussions to accelerate decisions. It’s how you spot friction early, unblock teams fast, and keep momentum without bureaucracy.
Be in the trenches with the team, join calls, have short demos, set goals on the call. At TryHackMe we expect all leaders, and PMs to be in the details. There is more to say on this section, especially as a fan of founder mode, but thats for another post.
Daily updates for short term projects
For short-term projects, asking for daily updates from the team helps with wider awareness of project development. It drives urgency by making everyone’s work highly visible and gives you the opportunity to comment on, stop, or push harder on specific tasks. 8 hours a day is a lot of time, so you should expect meaningful updates from each person. Daily stand-ups also work well.
Reward and recognise
Celebrate wins publicly so the team feels the impact of their work - show them the results and bring them along for the journey. If they’ve been working late nights or weekends, recognise it properly: reward them financially, but also give them time to recover. In the past, I’ve had teams expense dinners with their families as a small thank you, but after intense periods, it’s just as important to slow down briefly, reflect, and reset before pushing again.
Moving fast comes at a cost
Building fast does come at a cost, and its worth recognising:
Team burnout and churn can happen when you move fast - that’s the reality of pushing hard. We operate like an elite sports team, where the focus is on performance and delivery, not comfort (but with recovery and support built in to sustain peak performance).
Code quality might take a hit when you choose to move fast. In a startup, speed is what keeps you alive long enough to grow and win; momentum first, cleanup second. Keep a basic standard, expect some bugs, and fix issues fast. That said, getting faster at writing code - through AI, automation, and better pipelines - means speed and quality don’t have to be at odds. Expect some bugs, but as long as the team is fast to fix issues, it’s a worthwhile trade-off.
Creativity can take a hit when you move fast, which is why you need discovery upfront. Creative prototyping and building don’t happen at 100 miles an hour - they come from deep, obsessive thinking over time. Without it, you’ll sprint in the wrong direction, iterating on shallow ideas.
Moving slow comes at an even greater cost
Moving fast comes at a cost - but moving slow is even worse. You lose momentum, and eventually, your edge - if you even had one to begin with. Teams disengage when projects drag, and top performers won’t wait for slow decisions. If you’re a small startup with something valuable, expect competitors to copy it - so move faster and build on momentum while you’ve got it.
Conclusion
Thanks for reading! I’m sharing 2 more tips on my Slack - join to find out (its free).
Unbelievable, it's not for everyone and that's what we want.