On the focused effort of making a working prototype
There are many ways you can determine whether a new feature will add value to the product or turn out to be a complete waste of time. For instance, you can undertake user research, analyze the demands of the market, and study existing solutions. However, we (developers) have a fantastic tool in our sleeves: Developing a running project that demonstrates the proposed solution’s key ideas is your optimal option — in my opinion.
Here’s why.
Just one small thing: what do I mean by “demo”?
Well, a demonstration, also known as a customer acceptance test, is usually performed by showing the product or feature to stakeholders within your organization shortly after completing it.
Its main goal is to make sure everyone knows what you will be releasing and reduce the risk of investing time in the wrong direction. It should keep everyone on the same page and lead to a better product and happier customers. Thus, the demo plays an essential part in your decisions.
Therefore, focus on developing the most valuable features and code them as quickly as possible, but don’t compromise over quality. Write down any shortcuts and obstacles you’ve found on the way. It will help you in the future when it’s time to decide which product to put on the road map.
If done often, demos create accountability, a drive to deliver, which supports the team’s continuous improvement. Furthermore, as a by-product, the demo allows the team to be proud of what they’ve developed and have dedicated time to celebrate small wins. A word of advice: be careful of demos that are too polished. You might create a false impression among participants that you’re ready to launch when that might be far from the truth. To prevent confusion, clarify which shortcuts have been taken and what is left to be done.
Until now, I’ve been talking about demos in the software development life cycle. But there’s another way to do demos — a PoC, or proof of concept. PoCs are usually done in the developers’ environments, without any software ( QA ) testing, with some cut corners at times, but with the goal of getting quick feedback. The purpose is to keep the team “in shape”, meaning preserving their ability to quickly create solutions while deep diving into new tech stack, development methodologies, and more. This method is highly recommended to busy Individual Contributors who don’t find enough time to play with the code.
Simply put, I believe demos, regardless of how they are done, are an excellent way of sharing knowledge with others, learning new stuff, and generally keep improving one’s work.
Top comments (2)
That's a good point. I guess if your intent is to demo you will start thinking about the questions others may have to your implementation once it's demoed. And that in turn will make you more focused on the desired business outcome avoiding overengineering less-relevant bits.
True!