Digital product development is a relatively new field, combining technologies and disciplines in a way that has not been done before. This, compounded with the limitations of waterfall-style product development is why it fails so often.
The result is an end product that doesn’t do what it’s supposed to or misses entirely the needs of the customer. A lot of money is wasted on building something nobody wants or needs.
Based on my own experience as well as examples I found throughout the web I would like to draw your attention on common pitfalls you should avoid when designing or developing software this way:
- Not having clear requirements
Requirements are needed for everything from defining project scope to estimating final cost and schedule. Without them we will build whatever we think can be built without knowing how it can be useful or how much effort is needed to build it.
Reality is simple: Requirements are a commitment. If we have them, we know what to expect and have at least some plan going forward. Without requirements any estimate of time and/or cost will simply mean nothing.
- Not enough emphasis on software architecture
Every large system is built out of smaller components. We should know how these components interact and what the responsibilities of each component are. If we don’t, we risk having to refactor our software under time pressure because it’s impossible for us to easily extend or maintain the current structure. More often than not this results in having a spaghetti code like:
If you think that your project can run fine without any formal design and documentation please keep in mind that your project will probably fail due to: – Change requests; – People leaving; – Bad management; – Business requirements changing drastically.
- Not using source control system (or versioning tool)
Unless you like losing work, carefully managing all changes into a central repository is a must. Without a source control you will find it very difficult to work as a team since every developer’s version of the software will eventually drift apart, making integration and debugging difficult or even impossible.
- Using a language that you are not familiar with or don’t have some expertise in.
Although this is obvious, many people would still decide to use it for the first time on their pet project. This kind of decision can easily result in up to one year loss. Don’t be silly – if you want to try out some new technology/language/framework then do it in your free time first!
- Not owning or testing the deployment process
As surprising as it sounds, many first-time projects fail due to lack of production-level code quality and proper test coverage which forces developers after some time to rewrite major parts of the application . Without having at least an automated process for deploying and running your app in a production environment (even better in multiple ones) you will find yourself in a very difficult situation when it comes to deploying your changes and updates.
- Not having a plan B for the funding
Many projects which are created with a goal of making some money tend to fail not because they don’t have users, but because they never implemented any clear strategy on how to monetize the product . Without investing time into creating ad-hoc analytics and marketing plans for growing revenues, many startups get stuck at their bootstrapped phase due to lack of capital, leaving them unable to scale or pivot. It’s always better if you can afford hiring someone from day one who specializes in this field – otherwise make sure you invest enough time into researching the market and figuring out your marketing and monetization strategy before you write the first line of code – this will save you hundreds of hours in future.
- No clearly defined and documented product roadmap:
Most of the founders start working on their Minimum Viable Product (MVP) without thinking about the actual scope of features they want to cover in future versions – this leads to building a rigid, inflexible product which is hard to scale. A good approach that Chisel has followed would be to keep all your planned features in an excel sheet so that you can see what’s coming next and don’t over engineer the MVP.
- Choosing unsustainable monetization strategy:
There are various tried-and-tested business models like: Freemium, Subscription or Ad based model – but choosing them requires conducting market research and product validation . Also, make sure that your chosen monetization strategy will sustain itself long-term.
- Underestimating market size:
To build a successful business, one must look for a large addressable market (or customer base that is enthusiastic and passionate about the problem you are trying to solve). Make sure to deploy tools which can help you do extensive research on your potential customers . It’s also important to understand the exact problem your customers face and how it fits in their current workflow – this will serve as an excellent foundation for building a product and refining it based on feedback from early adopters.
