Five tips for exploring new project ideas
1. Start by understanding the needs behind the project.
Customers understand their problems well, but may not have a clear picture of a good solution. It’s up to you to figure that part out.
Ask questions that reveal the goals of the people involved in a project, so that you can think through how to best meet their needs. Focus on the job to be done , not just the implementation details.
Also pay attention to data: Knowing what data is available, what will need to be collected, and what a system will generate is helpful in the early stages of a project. You can work real data into early examples and conversations, to confirm your understanding of the problem space.
If there are other systems in the mix you need to integrate with, you need to find that out early too. Nothing is worse than building a project assuming it will work standalone and only later find out it needs to be glued together to countless other tools you haven’t researched yet.
2. Use wireframes to set expectations about functionality.
Wireframes are powerful because they immediately and clearly communicate the basic structure of an application without getting bogged down in style details.
Rough sketches help make sure that you and your customer are on the same page as to what will be built, and they can be updated quickly to adjust for misunderstandings or to explore new ideas.
Wireframes also serve as a useful tool for surfacing implementation details that are worth thinking about in the early stage of a project. Take another look at the two different wireframes for a video recommendations feature shown above, and ask yourself “how would the backend code look for each of these options?”
The ability to see all of the relevant elements for a feature at once lets you quickly imagine the interactions between them, and also encourages you to drill down whenever you want to mentally work through how each individual element might work.
3. Set up a live test system as soon as you start coding.
The point of rapid prototyping is to reduce distance between everyone involved in a project: both between developer and client, and between client and customer.
To serve both of these purposes, having a running system that everyone can interact with from day is essential: it promotes trying things out rather than simply talking about them, and makes it easier to share progress as you go.
The initial setup for a live test system needn’t be production-ready. It just needs to be the bare minimum setup that will support the product tests you are running.
Application hosting platforms (e.g. Heroku or similar), are often useful for building live test systems — but anything that will get you from zero to your first deploy in a few minutes is good.
4. Capture everything, then defer the nonessential
In the early stages of a project, you will get a lot of feedback. The problem is that it won’t be neatly prioritized; instead it’ll most likely be a jumble of problem reports, questions, suggestions for revisions to be made, and ideas for the future.
To sort things out, focus on work that provides maximum risk reduction for minimum efforts. Well-understood issues can wait until later — things that are less certain can be experimented with through technical spikes, mockups, and minimum viable feature development until they’re no longer the greatest source of unknowns.
If there are several possible paths forward that seem roughly equal in their level of uncertainty, think about the additional forks in the road that you’ll encounter down the line. Choose the task that when completed, exposes the most information about what the next set of tasks might be.
If you can draw a ring around a set of features that are relatively well understood and seemingly useful, that’s the time to stop prototyping and switch to production development mode. If you end up lost in the weeds or hit a bunch of dead ends, then you need to go back to the drawing board.
Make sure to get to one of those outcomes as quickly as you possibly can.
5. Check your assumptions early and often.
Although the general rule of prototyping is that actions speak louder than words, you still need to discuss where to take things next at the start of each iteration.
Sometimes it pays to ask a question, even if you think you might know the the answer. In doing so, you can both validate your assumptions and also get more context on how other people see the problem.
When exploring ideas, it’s best to ask open-ended questions. So instead of saying “Should I do X this way?” — ask “Do you have suggestions for how you’d like to do X?”Another good question to ask is “Once X is built, who will benefit from it and how?”
Asking these question will either reveal the expectations of the other person, or set the stage for a conversation where you can contribute your own ideas.
If instead your goal is to get your proposals approved, or you’re just trying to give stakeholders a progress report — then it is better to state your intentions rather than asking for permission. Simply saying “I intend to do X, so that we can Y” will help other collaborators identify when you’re headed down a wrong path, and it forces you to clarify your assumptions rather than keeping them up in your head.
If you enjoyed this post, you may also like Programming Beyond Practices.
