Custom software can, and should be, revolutionary. You build it to change your industry, to gain market share, to increase efficiency and productivity. You build custom software to make your business money.
Everyone starts the project wanting success. Business wants a product that will deliver what it needs. IT wants to write usable, sustainable code. Customers want to fall in love with your product and enjoy the value it adds to their life. Despite everyone’s best intentions, we know that almost 75% of software projects fail. Why is that? There are a lot of specifics to site, but when we take a good look at it, we can identify perfection as a driving factor. The human desire for the PERFECT product can cause the project to go over budget, over schedule, and miss the mark.
Software development by its very nature is evolutionary. Grab your phone and take a moment to open a couple of your favorite applications in your online store. Check out the version history to see just how many releases deep your love really goes. Chances are, you won’t find a 1.0 on your list. I checked out Snapchat while I was writing this blog and the current version is 10.61.1.1. Last month was 10.59.0.15 and six months ago was version 10.47.5.13. They release often with ongoing improvements, new features, and bug fixes.
No matter how perfect you think your idea is at the start, your software will evolve. You will change your mind as you interact with the software. Your users will provide feedback that will change the software. The world will change, and your software will need to change with it. Successful software iterates, quickly and repeatedly, to stay ahead of the demands of the market.
So how can you make sure that your software product delivers value without letting perfection get in the way? Allow space for your product to evolve.
5 Ways to Create an Evolutionary Software Product
1. Start with a Minimum Loveable Product
You want to put out the best first product, one that is more than viable–one that is lovable for your users. To do so, you will need to commit to participation in every step of your build. Start by listing out the core functionality and be brutally honest about what needs to be built versus what are ‘nice to haves’. A minimum product does not mean a lower quality one, but simply a lightweight version. What you want will likely change as you use the product, so don’t try to add every single feature you want now. Once you have your streamlined version, divide it into sections that you can design, build, test, and adjust in tight loops. Sketch out the first slice and design a basic wireframe and requirement. Get feedback and an estimate from your developers. Let them build this piece while you start the next. You want the product back in your hands quickly.
2. Stop Planning for Perfect
It is human nature to find comfort in planning. The belief that it is your job as the business owner to have all the requirements perfectly created before beginning development is a hard one to overcome. Often, business leaders spend too much time, energy, and money debating, designing, and prototyping. They avoid making decisions and sticking to them, dragging it out until they think it’s the perfect choice. It doesn’t need to be perfect the first time – in fact, expect that it won’t be! Instead, all of the back and forth before any work has started holds up their technical teams. They spin in over-analyzation circles working with analysts to create large requirements documents believing this will make the best use of the time of the developers. In reality, it usually results in developers writing thousands of lines of code that will never be used, which means hours of wasted development time. Over planning leads to over writing which leads to over budget.
3. Embrace Short Feedback Loops
Once you have your first item back from development and testing, you may find that it was built EXACTLY like you requested, but it is still not exactly what you want. Yes. This is why software built with short feedback loops has higher satisfaction rates. You want to make adjustments before you are so far along in the project that it is cost (and time) prohibitive to get what you truly want and need. As your software features move through the development life cycle, you need to cycle through Learn—Build—Measure. Scrutinize your finished features and give honest feedback, then use that to inform the build moving forward. During the testing phase, know what is most important to you and measure it. It is crucial to constantly evaluate and refine to keep improving with each iteration.
4. Learn to Question Bugs
What is a software bug? The simple definition is a failure or flaw that produces undesired or incorrect results. When a bug stops functionality, it needs to be addressed and in a very timely manner. The more functionality it derails, the more critical the bug. Not all bugs are functional, however. Some are simply a matter of choice. For example, what happens when a user hits save is a choice. When you hit enter, it might save and return to the same page vs save and return to the user to a different page. The enter button functions properly, but there is a different behavior than you were expecting. Perhaps you did not specify the behavior in your requirements but assumed how it would work. Maybe you did put it in the requirements and your developer made a mistake. Now what? Question it. Do you like it as is? If not, do you need it changed for this release? Would it make sense to log it in as a bug but wait until a later time to make the change? Assign categories to your bugs to help keep track of what needs to be changed now and what can wait. If it is important and you do want it changed, this can be an excellent example of where a short feedback loop can save time. Your team can learn from this feedback and adjust for similar instances in other sections of your build.
5. Your Team Builds with You, Not for You
The most important person in a software build is not the architect, it is the business product owner. Only you know what is in your head. As much as you try to describe it to others, there will always be misconceptions. If you are interviewing custom software firms who claim expertise and they tell you “we will take it and build it and bring it back to you in X number of months,” you should stop the conversation. You will likely end up very disappointed when you see your finished product. A successful build will require your participation regularly and consistently. This may be daily or weekly depending on the type of product you need but going a week without active work on your part is dangerous. If someone asks how your build is going and your response is “I am not sure” know that you are in danger. You should be able to bore the socks off anyone who asks because you know TOO much.
Building a software product is complex. It takes time and attention, evaluation and feedback, and a strong technical team supported by business leaders. However, that shouldn’t scare you from building your own custom software. It’s a fantastic opportunity to really think about how your business works and completely transform it to benefit you for years to come. A product built to evolve is a good investment. Your software will stand the test of time, keeping pace with changes in your business and industry.
In fact, a thoughtfully designed product can begin delivering ROI in it’s very first release. Design a great first release by focusing on what you need to make your users love it. Avoid postponing decision making, over-analyzing, and creating large requirements documents. Learn, build, and measure throughout each iteration to allow for quick adjustments to get what you really need. Evaluate any bugs and give precedence to those that have the most impact on the overall product. Participate consistently so that you always know you are on the right track.
By partnering closely with your development team and using these simple steps, you can ensure that your focus is on the profitability of your product, not the pursuit of perfection.