Having been building product full-time for over a year now I put together a collection of mini essays describing some of my philosophies, thoughts and learnings.
Ship at all costs
We have a singular goal as product teams: to ship software
You should be bullish about it. You should measure your progress as a function of how much you ship.
Waiting on copy? Write your own. Designs aren’t specific enough? Make them up. Waiting on marketing assets? Find them yourself.
Show the world what you’ve got, they’re best placed to judge. If something’s not good enough someone will let you know. By virtue of proving you can ship quickly you have proven to yourself that something can be changed quickly if needs be.
Your impetus should always be to ship.
If you’re ever unsure if something is worth shipping ask yourself the question “Is this a net benefit over what currently exists?”. As long as the answer is yes then go with what you’ve got. Better is progress and progress is momentum.
Waterfall in disguise
The 1980s.
A decade in which software still lived on disks.
As a result, software was expensive to produce and impossible to iterate on once released. To make software in any way economically viable we were forced to work in long development cycles with no time for course correction throughout the process.
Waterfall development was a necessity.
…
Today.
We’re afforded the luxury of being able to make changes in minutes. We have shorter development cycles and ways of delaying costly decisions until the they become blockers. It’s fair to say that waterfall has fallen out of fashion, rightly so.
But that’s not to say that it’s gone away.
Waterfall isn’t defined by a projects timeframe but its sequential nature to product development. Each step informs the next, and decisions made in earlier steps make changes in the current step prohibitively expensive.
While we mightn’t be Niagra fallin’ anymore it’s possible still to produce products in a waterfall like fashion.
The key benefit of shifting to agile style processes wasn’t actually that development cycles got shorter but its by-product; that feedback cycles were reduced and thus assumptions were validated sooner.
If the starting line is a concept and the finish line is a release, you shouldn’t optimise for getting from A to B in the exactly allotted time frame but rather you should focus on getting from A to B as many times as possible in the time allowed. There’ll be trade-offs and scoping decisions to be made each time you go from A to B, but force yourself to get through the loops quicker each time by chewing on either end:
Scope uncomfortably tightly, release uncomfortably early.
Worried about it missing critical bells and whistles? Chances are you don’t need them in the first place, and even if you do they will be added during the next loop, if time allows it and they’re important enough.
What you end up with at the end of the project will be different than what you expected you would have built at the very start, but embrace that excitement. No one enjoys a movie when they’ve already written the script. It’s better to make things up as you go.
Address ambiguity
Ambiguity breeds inaccurate estimates. Inaccurate estimates lead to inaccurate timelines and goals becomes inaccurate guesswork.
Ambiguity is unavoidable but knowing ‘The Three Truths of Ambiguity’ can greatly increase your chances of overcoming it:
- Ambiguity hides in the shadows
- Ambiguity must be confronted (Fight)
- Ambiguity can be outsmarted (Flight)
Let’s talk about each of them in more detail:
1) Ambiguity isn’t the known unknowns. It’s the unknown unknowns. It’s the parts of a project that we develop a schelp blindness towards.
Ambiguity fools us into fallacious thinking. It tricks us into thinking most about the stuff we’re intimately familiar with rather than that which which we have little or no context.
Fighting it requires you to put proper guard rails in place. Ask yourself what you’re least familiar with and deep dive on that. Pick the sparsest part of your tech plan and elaborate on that. Ask others with more context to cross reference your work to expose the blind spots in your thinking. Share tech plans and research findings with the right people and ask for feedback.
Whatever you do, don’t let ambiguity allude you.
2) Prioritising tasks based on which you’re most comfortable with is a sure fire way of delaying any project.
There’s a reason the 80/20 rule holds remarkably true - because 80% of the work is left until the final 20% of the project. An illogical proportion of the work is hidden by ambiguity.
Not all tasks are created equal but they can certainly be construed that way.
Instead, prioritise tasks based on which you are most unsure about. The upfront cost of knowing all your unknown unknowns pays dividends down the line. Discover the unknown unknowns when it’s still cheap to do so; during whiteboarding sessions as opposed to three months into a project when significant resources and efforts have already been invested.
3) Ambiguity can be outwitted.
The easiest way to address ambiguity is to avoid it. Addressing ambiguity is costly and is only rational when it blocks progress.
If something is unclear, ignore it. Shift your focus to something else. If it warrants being addressed it will continually crop up. Delaying decisions allows for more concrete ideas to be explored. Cementing them may indeed clear up the original indeterminateness.
Spinning your wheels on a decision is a telltale sign of ambiguity. Involving more and more people in the decision implies that there is no clear cut answer, at which point you’re taking a stab in the dark anyways. Choose to spend your time on something else you’re more sure of instead because a misstep is more costly to your product that a small step in the right direction.
Beta scourge
Betas are dangerous.
They are a limbo; features languish in them. They offer a false sense of security. They have all the illusion of a feature being released without any of the benefits.
Betas are not staggered releases. Stop thinking about them as first versions. Getting to beta is never the goal; it’s not something that should be celebrated. It’s another step in the process that isn’t “shipped to all”.
Betas should be avoided unless you’re looking to learn something. Even then you should strive to set clear goals of what you want to achieve from the beta, time box it, measure it, make a call and move on.
Betas should never accumulate features. They should operate under a FIFO style system, the longer something is in beta the sooner you should be looking to release it. Betas shouldn’t become bloated. Continually adding “one more thing” to a beta is a sure sign of scope creep.
Just because one part of a project needs to go through a beta doesn’t mean that it should put the rest of the project at risk. You should always look for ways of separating those parts of a project that need a beta from those that do not. Release the parts that you can immediately and follow up with everything else once it’s ready.