Each month Gordon gives an insight into building a software testing business. Each post has a focus on a particular aspect of the business. This is Gordon’s last blog post before he takes a break from the Start-Up series. If you would like to browse the other posts, you can catch all the Huddle Start-Up series here.
Introduction
Last month I discussed the difference between marketing and sales. This month, we’ll take a look at building a start-up product. Although potentially the most easily to connect with for software testers, I have deliberately left it to now to emphasise other areas of business which may be entirely new to founders of a new start-up.
These are all thoughts from my experience at my start-up company, CodeFuse. For a part-by-part breakdown of this blog series please see Part Zero.
A Quality Product
Writing code is easy. Writing good code is easy (under the right conditions). Writing code that delivers significant value to an end user is tough, very tough.
Straightaway, this reminds me of where my career as a tester had taken me. Too often testers are concerned with finding technical bugs. Not that that’s unimportant, it’s just a third of your job. To me if you can satisfy the following three areas, you have a high quality product.
- Technically sound
- Delivered in an efficient manner
- Delivers value to the end customer
Who cares if you have delivered a bug-free product that was a year late, the markets moved and the end client has lost most of the value of the initiative?
Who cares if you delivered a bug-free product on time that nobody ever uses?
And yes, for completeness, who cares if you had the solution to a key customer problem, delivered it on-time but then it was so riddled with bugs the end user couldn’t be bothered with it?
Working in a big company, the easiest of these for most people is making the product technically sound. To make things more efficient you probably need to battle a bit with middle management or co-workers. To challenge the value of what your team is doing is often going in for full-scale war.
But you’re not working for a big company now, you’re a start-up.
Determining value – the Minimum Viable Product
And enter the ubiquitous but often misunderstood MVP (Minimum Viable Product). It’s a very powerful concept.
As you build your company you need to deal with the biggest unknowns and risks first. Why would you start with the stuff that you know can be done, only to find out after a few months that other things are a bridge too far?
For most IT professionals, you know what is possible in tech. You probably either know you can build your idea or not. The trickier question is whether end customers can see value in what you propose to build. And what exactly is the scope of that proposition. You need to validate that your product or service is desirable at a viable price point.
This helps reinforce the idea that it’s not a prototype you are eventually going to build. It has to deliver 100% of something of value to somebody. That’s not to say 100% of your vision. But effectively you need to build something that works, is useable, looks OK and ideally that someone is willing to pay some money for. This diagram is really useful here (taken from here).
You do not want to build a prototype that does 80% of everything. You want a product that an end user wants to have.
The Good, the Bad and the Ugly
Making it too Good
So the MVP question is trying to steer you away from building your whole vision in the first incarnation. You don’t want to make it “too good” with bells and whistles. Some of those may just slow your progress to getting revenue. Some of them may actually be a negative. Adding more and more features is just a recipe for more and more regression testing. It can also slow your development time exponentially if you are adding features which are fundamental and interact with many others. The irrelevant features just add more cost to the relevant ones going forward.
Furthermore, it’s not a good idea to build a product for the long term when you barely have a short term. It is a poor decision to delay revenue because of things that may never happen. Just have a solid plan for how you are going to scale in the future.
Making it too Bad
Conversely, there are some decisions that are worth thinking about. Thinking about the “efficiency” side of quality, you do not want to spend time and money re-writing code in different technologies a few months down the line. Refactoring is absolutely fine, but complete re-writes should be avoided.
Likewise, some design decisions are just bad because you don’t know enough about what your customer expects and what they will put up with. Try to get detailed info before you code!
Pay serious attention to your user experience. A reasonable, functional product can be really let down by a clunky interface. And unless you think about the workflow at the start, it can be tough to alter without a big overhaul.
Making it too Ugly
Also, it’s conceivable that an end user could find your product great. But you need to get them to hear your message. You may need to help the marketing effort with some “wow” features. These could be high impact productivity features but don’t underestimate the power of connecting with people with something that appeals to them as human beings. Can you add some visualisations to dry data sets for instance – it adds much more impact on marketing materials and at demos.
Conclusion
In summary, some of the things to think about to avoid some of the pitfalls which we have experienced are as follows (although I’m sure there are plently more!)
- Identify your MVP.
- Think about your underlying technologies at the outset.
- Think about the UX right at the outset.
- Don’t ruin your MVP by adding superfluous features which are not absolutely core.
- Get something useful out there now but also have great plans for scale.
- Make something eye-catching about your product.
More broadly, if you are a tester starting a new business, use your skills beyond the technical. Carry on testing. Dream up the right tests though. Test your product. Test team efficiency. Test underlying business assumptions. Make a high quality product, and business, that you can be proud of!
I hope you have enjoyed this start-up series and feel free to get in touch through www.codefuse.io or connect on LinkedIn.
About Gordon
Gordon is the founder of CodeFuse Technology. CodeFuse reduces software development time by making regression testing faster, better and easier. Gordon graduated with a 1st class degree in Computer Science and Artificial Intelligence at Sussex University and also holds an MBA from Imperial College with a specialisation in Entrepreneurship. He has worked successfully for blue-chip, SME and start-up companies. His passion is software quality and making sure that continuous improvement is used to enhance quality efforts across the entire development lifecycle.
