You're planning too much

Humans love to make plans. The desire to plan is natural, but is ultimately based on fear. You have limited resources to make your dream a reality and the worst thing that can happen is that you get halfway through the project and run out of time or money. To prevent this, you spend coutless hours planning what to build, in what order, endlessly hashing and rehashing the product until you feel ready.

Here's the problem: you'll never feel ready. Building an MVP is a process of discovery, and everything should be flexible. You need to be ready to throw things out, redesign them, and skip features entirely. To paraphrase von Moltke: no battle plan ever survives contact with the enemy! This applies to software in addition to business and war.

So what do I do?

Don't take this to mean that you shouldn't plan at all. Requirements, wireframes, and product roadmaps are all critical to building software successfully. What I'm saying is that if you have those things (and you've matched them to customer needs!) then what you have is probably good enough to get started.

If you're not sure if what you have is good enough, send me an email at me@jeremyphelps.com and I'll be happy to take a look for you.

What happens after development starts?

Expect to keep track of your developers closely at the beginning. Check in with them at least daily, preferably multiple times per day via Slack. You must make yourself available to them so they can ask as many questions as needed. If you can't commit to this level of collaboration then you need to find a Product Manager who can or postpone the project until you have more time. Do not expect to simply leave your developers to their own devices and check in weekly!

Uncover unknown unknowns

No matter how much you plan and research ahead of time, there will be hidden pitfalls in your project. An integration won't be available, a library won't do exactly what you expect it to, or the requirements will change. Your goal is to root these out as quickly as possible. Ask your developer what he or she is most uncertain about, then attack those tasks first.