Starting A Large Undefined Project

Problem

"I've often been faced with wanting to build something but not yet having a good sense of exactly how. Maybe you'll have an idea, such as a way for developers to interact with your servers, but you aren't at all sure how to go about it."

Actions taken

"Many of the steps you should take seem obvious in retrospect, but you'd be amazed at how much you forget about them. First, you should talk to the people who you know want the solution. This can be harder to do if you don't yet have customers, but if someone internally is asking for it, talk to them so you can understand as much as you can about what success will look like before you write a single line of code."

Next, write some extremely basic 2-3 page use cases to make things more concrete. Inside of these, do some drawings for yourself. It's much easier to be vague with language than with drawing, so this helps you to be as clear as possible. Once your use case is written, show it to the person you spoke to earlier to get feedback.

Once you feel good about your use case, do the simplest version of building this product that you possibly can. Your goal here is mainly coming to understand what will be hard or even impossible based on the ideas that you have. You will probably already be aware of things you think will be hard, so this helps you to determine how hard they will be, but it also helps you to identify things you don't realize are hard through engaging with the problem. This is hugely valuable because it helps you to avoid doing months of work before becoming completely stuck.

Once you have built your first prototype, take the opportunity to talk with your stakeholders. I like to do this by having regular sprints. Then, once every two weeks we show stakeholders the work we have done, gather feedback, and drive forward based on that feedback. This is even more valuable when you don't know what you're building than when you already have an established product.

What you're looking for throughout this process is whether you're focusing on the right problem, whether it's a valuable problem to solve, and if you're solving it in the right way. Eventually, you'll come to a place where it feels right and you can then decide on how much of the prototype to use and how much to throw away.

Lessons learned

"You want to make as lightweight and as fast a version of a product that is as real as possible early on. This will help you to get really high-quality feedback about whether it's the right thing to build and will ensure you understand the problems you're going to hit as you try to build it yourself."