Get Intimate
intimately understand why you’re building what you’re building, and have the conviction to back it up
An easy way to gamble on the future success of a product or feature is to not think it through. Everything might work out great, or it could all crash and burn. Instead, take the time to understand the true value the idea provides to someone - what problem it solves and the motivation behind it.
“Working Backwards” by Bill Carr and Colin Bryar suggests writing a “PRFAQ” which is a press release (directed towards your future customers) coupled with anticipated frequently asked questions. This provides a medium to encourage clarity of thought, especially concerning the motivation and other important details such as potential risks and how to mitigate them.
I think it’s a perfectly valid approach and have used the technique myself to help with communication to stakeholders. I don’t, however, think it’s the only approach.
What’s key is that you intimately understand why you’re building what you’re building, and have the conviction to back it up. When your product manager, CEO, partner, or the voice in your head questions a piece of your game plan or suggests removing a feature- or when you need to estimate scope- you need to understand what exactly you’re working towards, and what’s needed to get there.
Once you have a clear understanding of what you’re trying to achieve, you can start to make a plan on how to approach implementation.
Aggressively Descope
Prioritize and get creative. Cutting corners and creating short-term, contained tech debt might provide a pathway to shipping months sooner.
Building things is slow. It always takes longer than it should. When you’re working with others, even if they’re rockstars, things take longer than you think. So, people subscribe to all kinds of techniques to estimate as accurately as possible- and then they double everyone’s estimates- or triple them. Now, it’s going to take longer to build, but you just add more resources to the project. Or allocate more time for the project. And suddenly you’re talking about shipping in 4 months - or 6. It’s incredible how quickly something that should take weeks will suddenly take months.
I’ve heard stories of products built over the course of months by a team of engineers that were rebuilt by a single engineer over a weekend and was a dramatic improvement, in terms of speed and user experience. Maybe the stories were exaggerated, but I can believe it. And it’s probably not because they were a one-in-a-million 1000x engineer. I would guess they deeply understood the core value proposition of the product/feature and aggressively descoped until they could deliver only what was needed to provide that value.
When you have insight into the process and context of building the idea out, you are granted a superpower of anticipation into what aspects will take the longest (or be the most draining) to build. Unless you’re going straight to general availability (and maybe even then), you don’t need to build the perfect product out of the gate. Prioritize and get creative. Cutting corners and creating short-term, contained tech debt might provide a pathway to shipping months sooner. But, be intentional. It’s very easy to be a tactical tornado, leaving a trail of tech debt with every commit- this is not what I’m suggesting. If an aspect of an idea might not even be something a customer ends up wanting, why spend time crafting a long-term, maintainable solution?
Build exactly what is needed to deliver the core value proposition to customers.
Relentlessly Focus
When you can see every step of the path forward in front of you, following it is easy. With some discipline and practice, how productive you can be in a day might just blow you away.
The more intimate you’ve become with an idea, and how well you’ve limited scope, will build a strong foundation for being able to buckle down and build. When you can see every step of the path forward in front of you, following it is easy. With some discipline and practice, how productive you can be in a day might just blow you away.
People talk about “achieving flow” - a magical state of mind where you lose all concept of the passage of time and your surroundings. Where someone can achieve unfathomable feats of progress and taste what it might be like to be 100x engineer. I think it’s very achievable.
One formula might be “intimacy with an idea + clearly defined scope + prioritization + focus = flow”. In other words, you know what you need to build, you know what order to build it in, and you shut out everything else, and build it.
People have different ways of focusing, but noise cancelling headphones with white noise or music goes a long way.
And do it day after day. Don’t give up - keep at it. It can be a bit draining at first, but it comes with massive payoff. I consider this, relentless focus.
Polish
Are there any small adjustments (a few more minutes or hours of work) that you could make that would make the experience a bit better?
People talk about how important first impressions are. There’s a lot of truth to it- humans make snap decisions all the time. A bit of polish to an early version of a product or feature can be the difference between a positive or negative gut reaction.
Walk through the happy path. Walk through failure modes. How good is the first moment your end-user has with your product? Are there any micro-interactions that could be improved? Do things look good? Do you like the color palette? The font? Are there typos, awkward padding, misaligned components?
Depending on what exactly you’re building, all the questions I just asked could be pretty irrelevant, but hopefully it paints a picture of what I’m getting at.
Are there any small adjustments (a few more minutes or hours of work) that you could make that would make the experience a bit better?
Game developers might call this “adding juice”, which would entail anything that would make the whole experience just feel good. (think effective use of sound, animations, camera movement, etc.)
When approached the right way, a time-boxed session of polish can evoke a dramatically more positive response by an end-user. In other words - go the extra mile.
Worth noting, this doesn’t need to be limited to the core product - a bit of polish to distribution can also be incredibly effective.
Demo
When you build something - make a demo. It’s your time to shine.
Showing off your hard work can be nerve-racking, exciting, and monumentally valuable. Creating a demo gives you an opportunity to craft, solidify, and communicate a narrative to someone watching it.
When you work incredibly hard, and spent time making a great plan, and executing it- getting to show off your work to your co-workers or a community is so satisfying. Anticipating how you’ll wow people is also a great motivation when you’re putting in the time.
Avoid smoke and mirrors. Push yourself to only show something real. It’s amazing what people can create when they hold themselves to a high standard.
When you build something - make a demo. It’s your time to shine.
(It’s also a great way to suss out bugs an end-user would run into)
Ship
Just ship it. Get it out into the world or in front of your customers.
It’s easy to have a first reaction that iterating or continuing to polish is the next step forward. Maybe building a companion feature, or keeping what you’ve built as part of a big shiny launch that will put you on the front-page of TechCrunch.
Just ship it. Get it out into the world or in front of your customers.
There isn’t just one opportunity to “launch”. You can launch again and again. If you don’t ship, you won’t know what people think. You can’t iterate and improve on the right things. Your competitor might get there first. You get the idea.
Ship.
If you’re doing something risky from a security perspective or are subject to regulatory compliance etc., then obviously take great care and don’t follow this advice - ask someone much more knowledgeable than me when you should be shipping. Don’t get in legal trouble or screw people over.
Validate
Setup meetings. Ask lots of questions. Find out how valuable each feature is. Find out what’s missing. Validate that it’s worth continuing to build.
So you shipped! That’s incredible. You’ve done something many only fantasize about. You’ve made something real. But was it the right thing?
That’s what you need to find out.
Distribute what you built to as many people as you’re comfortable. More than you’re comfortable. Make it easy to try out. The more people that try it out, the more likely you are to understand what value it provides, and what value it doesn’t.
Setup meetings. Ask lots of questions. Find out how valuable each feature is. Find out what’s missing. If you take it away, would they care? Validate that it’s worth continuing to build.
If you aren’t providing value, find out why. If a certain piece isn’t providing value, find out why. If it makes sense to rip out a feature or piece, rip it out. The less there is, the simpler it is to use, and the easier it is to maintain.
Once you’ve gathered all this feedback, you can reassess, and get intimate with your new vision. Make it real.
Great post Jason. You've packed a ton of valuable insight into a short post on a big topic. I personally love to use user story mapping as a process to get that well defined view, and to help organize the scope into phases. I think it helps with much of what you pointed out (in the dev phase) and doesn't require any engagement with estimates ;-)