I am part of a mastermind group of 4 entrepreneurs. Last week, one question that came up was “How do you keep the quality of your product up?”. As the only technical founder of the group, I could offer some suggestions regarding the software development aspect. Since my suggestions were well received, I thought I would try to capture them in a blog post. Please note that this is targeted at non-technical founders.
There are several checkpoints in the development of a new feature where you can check for quality. The earlier you find a bug, the cheaper it usually is to fix it.
Culture
If you run into product quality issues (bugs), the first thing to look at is your team culture. The two founders raising concerns about the quality of their product were also often referring to their velocity, which made me think velocity was important in their team culture.
If you have a poor quality outcome, maybe you are trying to go too fast. Try to reduce the scope of work per iteration.
Better to have half a product than a half assed product.
Something that can help you here is by improving your estimates. In the software development world, you can look at techniques like the Planning Poker. Planning Poker is a technique recommended as part of the broader SCRUM software development framework.
Check out SCRUM if you are not familiar with it. It has a lot of practices in place to keep the quality of your software up throughout the lifetime of the project.
Design
Sometimes, a feature is badly implemented because the specifications are not defined well enough.
Design quality in rather than test quality out
It is worth spending extra time in the design phase to ensure you cover all cases (blank states, error states, mobile version, print version, etc…) so that the developer doesn’t have to solve them himself/herself.
Development
To help developers remember everything that needs to be done during the development of a feature, make sure you have a well defined Definition of Done (another SCRUM concept).
It is basically a checklist of everything that needs to happen to a feature before it can really be considered done.
An example of a Definition of Done:
- Unit tested (where appropriate)
- Mobile friendly
- Documented
- Peer reviewed
- Deployed to test
- Validated by QA
- Validated by Product Owner
Peer review
Make sure that any code change is peer reviewed. The main two benefits of peer reviews are:
- Knowledge sharing between developers
- Increased personal accountability: when you know your work is going to be reviewed by someone else, you can going to make extra sure your work is fine.
QA
One simple and relatively cheap thing you can do to reduce the bugs that make it to the live product is to hire a manual QA tester.
We live in an incredible world where you can find a QA tester in less than a week on platforms like Upwork. Depending on the complexity of the software to test you could find someone for about $10 USD per hour to help you.
Get your testers to list test cases for each new features, and to test them manually before deployment to production or after big changes to the product.
Internal product demos
SCRUM (again) suggests having product demos at the end of each iteration where the developers have a chance to showcase their work and receive feedback from the team, product owner and stakeholders.
It is one thing to imagine a feature, it is another one to see it for real. The developers are likely to receive valuable feedback at this stage, even before a user gets to use the feature.
Post-production
Once a feature is deployed to the production environment, you can put things in place to lessen the impact of bugs:
- Error tracking: make sure these are reviewed regularly and allow time to work on the issues that come up
- User feedback: ask your users what they think about a particular feature
Conclusion
Quality in a product is an ongoing challenge you won’t solve in a week. Make sure quality is part of the regular conversations you are having with your team so that it becomes part of the DNA of the team. In doubt, look at the SCRUM framework because it has a lot of good ideas.
Do you have any tips for other founders?
