When a startup or founder approaches me with an idea they want to work on, I have a predetermined series of steps that I follow to keep things moving smoothly forward.
I've been through this process many times. The first few times I had to make something for someone else I just faked that I knew what I was doing. In reality I was absolutely terrified. As time went on and more projects came my way, I learned about what it takes to make a web product. So I started to experiment with it.
At present, the system I use to navigate a project has settled into a natural pattern, so I thought I'd make it into a short guide. This guide is partly for me to refer back to, but it's mostly to help anybody who's interested in improving their process.
The following plan is by no means designed. At least not self-consciously. It's a pattern that has steadily evolved from the demands of working on many projects of different scopes, scales, and disciplines.
It's even possible to pick parts from the plan à la carte and they should still work independantly. I do this all the time when I'm approached with a small chunk of work.
Out of all the entry points you can choose for starting a project, the easiest and most effective way I've found is to start by clarifying things.
What should you clarify? Things like vocabulary and concepts are a great place to start, since you'll use these heavily to think about and form ideas.
Every project comes with a unique vocabulary that has context specific definitions. It's crucial to be clear on these terms before progressing any further. Write them down where everybody can see them.
Clarification is more important for teams than it is for solo makers because it only takes one member of the team to have a inconsistent definition for parts of the project to gradually drift out of alignment.
A real example of how important it is to clarify things came when I worked on Just A-level. Over the first few days of the project I insisted we all worked clarifying common terms we used to talk about the app. Things that seem simple—like what a "Course" is in the app; what a "Lesson" is; what it means to complete something.
None of us knew the answer to these questions at first, but by discussing them we developed the building blocks we'd use in the subsequent steps to design and build the Just A-level product.
"The way to get good ideas is to get lots of ideas, and throw the bad ones away"
— Dr. Linus Pauling
Ideas are everybody's favourite bit of a project because, let's face it, ideas are easy. You get to daydream about an ideal future without the need to get up and make it happen.
The ideate step should involve everything from back of the envelope sketches to mockups and stories. The outcome should always be materials that express ideas.
The idea is to demonstrate sets of ideas or features without having to explain them. They should stand up on their own merit. This will allow them to be independantly criticised.
A great system for visual design is to create prototypes and then upload them to a service like inVision. Here mockups can be arranged so that it feels like a low-resolution version of the end product.
When I was working with BeachFix we used InVision to prototype journeys through the app by transitioning between all the different screen designs. We could then talk about the app as if it existed, but we only did about a tenth of the work to get there.
Be careful not to linger on ideas for too long though. It's a comfortable place to be compared with the next step. When ideas must come into contact with the real world.
Validation is tough. But it should be embraced as early in the process as is reasonable.
Validation requires a detached perspective so that outcomes aren't clouded. There's nothing wrong with hoping ideas pass the validation test, but it's best to approach them with a curious mind.
Why test ideas in the first place? Because who wants to spend time working on something that will be a flop on release?
Done right, testing ideas gives you a signal whether or not you're onto something. To put it bluntly: validation tells you if something is worth building.
How do you test an idea? It's a good question that benefits from some creative thinking. The golden rule for validation seems to be to put an accurate representation of your idea in front of the users you think couldn't live without it. Then observe carefully.
One of the many methods of validation is the method I used while making one of my web apps, Ripcast. Ripcast lets you generate podcasts from YouTube videos. I had a hunch that there was a crossover of podcast listeners and consumers of lectures and talks whom would find it valuable.
To test Ripcast I built a simple demo and then started trying to track down some target users. I introduced it on networks like Reddit, to friends via twitter and email, and asked for feedback if they liked it. The response I received back was pretty weak, but now and again somebody would love it.
You don't need much feedback before you make the decision to go with the idea or move on. Some see this as an art. To pick up on cues from users that most people wouldn't even notice.
In the end, with Ripcast, I moved onto other things instead of developing it further. It still has a small but active user base that converts and listens to ~10GB of content/month.
Remember I said validation benefits from creative thinking? Well, it's possible to validate ideas in lots of different ways, including with nothing more than a humble spreadsheet.
If you'd like to know more about validation led development I recommend reading The Lean Startup by Eric Ries.
Now that some of your ideas have passed the validation step, you should have an informed idea of what it is that you're going to build.
Developing ideas into software is the area where I have the most experience. This is probably true for most makers. Our instinct is to home in on the making part. This is probably a good thing because making the damn thing is always the longest part.
In this step designs are cleaned up and finalised. Lessons learned from validation are worked in, and code is written. Finally, out of the chaos a product will emerge.
Outcomes from this step are more ambitious than the previous steps because the develop step must produce a functional product or solution that fits the original brief or project specification.
To wrap up
For a long time the develop step is all I did for the whole project. I'd make some designs and then code them up. Simple as that. I made a lot of bad products this way. But it was a great way to learn.
You might have noticed that I didn't mention deadlines or planning. It's not that I don't work to deadlines or plan ahead, because I do. Deadlines just aren't a crucial component of making something. They shape decisions, but they don't have creative influence. Deadlineas are incidental to the creative process.
Another thing I don't tend do is split projects into types of work (ie. plan, then design, then development, then launch) like an assembly line.
Not only is this approach inefficient for making software with the internet, but it makes it near impossible to change anything that came out of the previous stage. So the product can't adapt to new information.
With this guide I wanted to record the things that I've had to learn the hard way. There's an endless flow of posts about how to meet deadlines and how to plan projects. I don't see many people talk about how to navigate the wilderness that is making something new. If this guide can help some of you do that, I'll be happy :)