Starting a project the right way.

You know those developers who start coding and ask questions later? You don’t want to be them. These fools rush in without defining the problem space.

The opposite of the kamikaze developer is not the clearly defined, well-analyzed project. It’s analysis paralysis. It’s that state of doubt, fear and indecision that drags on and burns into the project time. It’s where slideshows are made. And JIRA tickets. And oddly specific plans.

We want to find that sweet spot between building too soon and waiting too long. There are two rules in play here :

1. You can’t build what you don’t understand.
2. You can’t think yourself out of a problem.

You’ll want to develop a problem definition and a prototype that allows you to make an informed decision.

Write down the problem in 3 slides.

If you cannot explain the problem in 3 slides, you either don’t understand it or you’re taking up too much at the same time. The key to success in software projects is focus. Without it, you can’t be fast, lean or effective. So: make it very clear what you are trying to solve and for who.
Tip: present these slides to an outsider. If they don’t understand it, neither do you.

Draw the solution in one image.

If you start your product with a 25-page architecture document with seven layers and 35 components, you’re missing the point. Building a solution is not a huge upfront design. The first concept should be relatively simple. 1 slide with one drawing should suffice.
Tip: It’s the start of the voyage: you don’t know shit. That’s OK. Don’t pretend to have knowledge you don’t.

List 3 pros and 3 cons of the solution.

The pros should be easy: if you can’t say anything positive, why build it? The cons are a bit harder, but if you don’t know the drawbacks of your solution, you didn’t think it through.

Ready? Now go!

Build the smallest possible version of your solution. Mock everything that’s not critical. The idea is not to build the basis for future development. We want to make a cardboard model of the solution.
Tip: there is no QA here. This is throwaway code. If you catch anybody writing JIRA tickets at this point, they have to buy team lunch.

The entire trip from problem definition to prototype should take no more than a month.

Based on what you’ve learned now, does this solution make sense? Will it solve the problem or have we discovered new issues and opportunities?

There are three steps in starting a project: Fantasy, Prototype and Informed Decision. It’s only after you’ve built the mock-up that you can do any sensible estimation or planning.

Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.