A client comes to you with an idea—a set of goals they're determined to achieve—and they want you to help them. What do you do?
I've been in this situation many times. The first few times this happened I was absolutely terrified and played it pretty safe. 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 figured I'd write it down for the first time right here, right now.
The following plan is by no means designed. At least not self-consciously. It's a pattern that has emerged naturally through working on many projects of different scopes and scales.
It's possible to pick parts from the plan à la carte and they should work independantly. I do this all the time when I'm approached with a small chunk of work.
Why clarify first? Clarifying things makes the future less confusing.
What should you clarify? Things like vocabulary and concepts are a great place to start, since you'll use these later to think about and form ideas.
Every project comes with a unique set of terms that have context specific definitions. You need to be clear on these terms before progressing further. Think of this as the foundation of a project.
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.
It's useful to write down the outcomes of clarification. This will often develop into a project specification.
A real life 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 agree on common terms used in the app. Things that seem simple—like what a "Course" is in the app; what a "Lesson" is; what it means to complete something—are actually really hard.
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.
"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. This also explains Marxists.
The ideate step should involve everything from back of the envelope sketches to functional prototypes. The outcome will be ideas in a testable form.
The thing that makes it testable is the fact you can demonstrate the idea or feature without having to explain it too much. Final ideas should be in a testable form.
What's an idea in a testable form? The perfect example is a prototype made with a service like inVision, or an ugly prototype that demonstrates an isolated feature.
When I was working with BeachFix we used inVision to prototype journeys through the app by transitioning between different screen designs.
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. It requires a detached perspective so that outcomes aren't clouded. There's nothing wrong with hoping ideas pass the validation test, but always prepare for them to fail.
Why test ideas in the first place? Because who wants to spend time working on something that will be a flop on release?
Testing ideas gives you a signal whether or not you're onto something. Put 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, and observe carefully.
My preferred method 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.
By now you should hopefully have an idea that is worth building. So let's get down to it.
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.
What I didn't say
For a long time the develop step is all I used to do 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.
It was also a great way to learn. Validating ideas is good when you're trying to find product market fit, but a waste of time when you're learning how to design and build software.
Did you notice that I didn't mention deadlines or planning? I hope you did because I left them out on purpose. Its not that I don't work to deadlines or plan ahead, because I do. Deadlines just aren't that important when it comes to making something. They're an incidental fact outside the creative process.
Another thing I don't 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 old fashioned and inefficient, it makes it impossible to change anything that came out of the previous stage. So the project cannot adapt to new information.
With this guide I wanted to record the things that I've had to learn the hard way. Everybody already talks 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.