Every software company that I have worked with over the years follow a similar cycle when it comes to release cycles. You plan, you build, you Alpha, you Beta, you release.
I’ve always had a problem with this. The first time that you’re getting real feedback on what you’ve built is after you’ve built it!
By this point, it’s often too late to do anything about it. You may pick up bugs during Alpha/Beta testing that you are able to address before release, but what about the product itself? What about the design and workflows? If you’ve made a major mistake in those areas then you more than often won’t have time to fix it before release.
The problem is that a lot of projects will have Alpha and Beta testing written into their project plan. If that’s the case, then there is only a finite time allocated to it. If a major design flaw is recognised at this stage, then it either won’t be addressed, or the proposed release date is moved back. This is because Alpha and Beta testing is usually loaded onto the end of a project.
So why do we do this? Why do we ask customers, partners and other friendlies to give us feedback on something that we may have built months ago? And then, more often than not, have to ignore any feedback because we don’t have the time to address it!
There’s a better way.
Feedback should start at the beginning of a project, and not just within the development department. As soon as you have an idea for a new product, or an improvement to an existing one, you need to start the feedback cycle straight away.
You will hit key milestones in a project way before you have a finished product:
- Initial Requirements
- User Stories
- Slice plan
- Showcases at the end of each sprint
These are just some of the points that you will reach (or should be reaching) in every project, and it’s at these milestones that you should be sharing what you are doing.
If you’ve made a colossal mistake in your wireframes, or you’re not hitting the right user stories with your project, then you need to know before you start developing, not six months later!
It might not be anything major that you’ve missed, but if you’ve planned well up front then you should be able to give your stakeholders a good picture of what you’re trying to achieve. If they agree, great! You’re on the right track!
You don’t have to have a fully working prototype that people can get their hands dirty with. Talk them through some early features or designs, get their advice on what you’ve proposed on a high level. If you ask someone for their opinion, tell them that their advice is appreciated, very few will turn you down!
And don’t keep it internal. Remember, you’re not building software for yourself, you’re building it for people to use, enjoy and to make their lives easier.
Speak to customers, partners, industry experts. Speak to people who have used your previous products (if you have some), but also speak to people who have never used your products before. Get a wide spectrum of audience so that you get a varied range of feedback.
A common mistake is that you have to act on everything that’s fed back. Not true, although you do have to listen to every comment, you don’t have to implement every suggestion (you’ll more than likely get conflicting points on some aspects anyway).
Instead, look for themes and patterns across the board. If three separate groups are raising the same concern, then it’s likely to be a genuine one. If somebody is asking for a feature that goes against the vision for the product, then it’s ok to let them down, as long as you explain why.
Keeping this feedback loop open and getting people involved early will help everyone. It keeps the project on track, keeps confidence high in the development teams and also helps your key stakeholders feel appreciated and involved. These are the people who will be giving you free advertising once your product is available after all.
If your feedback cycle starts early, and continues throughout the life of your project, you can be guaranteed that you are releasing the right product at the end of it.