Ideas changing products

Deciding what to build, how to build it, and who should build it is at the core of getting the wheel turning.

It’s a deeply human skill that’s done a disservice by buzzy conversations about processes like “Agile” and “Waterfall”. The people who do this are genuine hero’s, and too often systems and processes steal their credit.

Start with what to build? Are you figuring it out? Are you trying to get someone else to accurately tell you? Is anyone here capable of figuring it out? How much needs to be learned just to understand what can be built?

Here’s the kicker: on any product you are making something new exactly once and never again. From that point forward you’re crafting a transition. You are here. Here is often incredibly nuanced an complicated. You need to get there. There is going to be even more nuanced, complicated, and it’s shrouded in darkness.

Ok, it’s you. You’re going to do it. You scribble your rough notes down on that napkin and you’re ready to go!

Incase you’re wondering: yes, it has to be incomplete for two reasons:

1) Your product is complex and inflexible (all software inevitably is)

2) Everything is constantly changing

In the hours, days, or weeks you spend planning your transition there’s a team of capable builders out there shifting around the very foundations of your product.

There’s millions more of them out in the world your product is aimed at, regularly tipping it on its head. Apple’s on stage again… and here comes dark mode, everyone get building!

Bigger teams have to deal with bigger problems, but even your team of one is chasing the world.

Right then, charge on because you do need to get over the hill and times a wasting. You have your rough plan. Who’s going to do it?

If you’re a one person team who built the whole thing, great! Grab your napkin plan, wipe down the screen of your Macbook (please don’t skip this step, things are getting ugly out there) and get typing.

You’re not a one person team? You don’t write code? Whoops. The “who” was probably the most critical input to your plan. Sorry, we’re going to need to start again.

If you’re going to get the intern to build it, well, you’re going to need a lot more napkins. Without knowing who you can’t explain how. You don’t write code? You can’t explain how.

Find people who know how to get from ideas to changes. Smart people. Technical people. Heroes. Without them, you’ll never get up that hill.

Zip zip!

The sprint to confusion

An interesting observation about writing software: you go and you go and you go, you build as fast as you can, you keep going, because the thing you’re working on isn’t real and doesn’t exist until you get it into the world.

And you slog through the valley of despair. You think it works! Watch out though: the swarm is coming. All the bugs start literally falling out in front of you. The edge cases abruptly start to bite. You keep going through bleary eyes, because it must become real.

And then with an overwhelming sense of relief, you ship it. It’s not as good as you know it could be, it’s not as great as it will be next month, but at last you can rest.

It’s this point right here that I find to be the strangest.

You don’t quite know what to do next.

You want to hide from the part you just shipped, hoping that you didn’t miss anything, hoping that it works in the world.

At some point, when your brain is ready, the cycle will begin again.

You wait. You wait for the rush.

Zip zip!