There’s always a tradeoff between three things when trying to launch – quality, cost and time. When you are dealing with uncertainty and trying to match up what is in your head to what will happen in reality, better to allow quick cycles of feedback to drive your launch. Otherwise, you can over engineer your solution without a real understanding of how your customers or team will actually use something.
So, whether you are trying to launch custom software, custom integrations or a useful app, it’s better to get immediate feedback and put the earliest versions in the hands of users. Then set expectations and make them part of the refinement and development process.
Thus your users are helping to test for any issues and give feedback quickly. Here are some best practices to guide that testing process:
- Make quick changes. Expect that there will be small issues and get those articulated and captured quickly.
- Itemize individual changes meticulously. It’s easy to blend problems together. It’s important to ensure high accountability and identify the specific issue concretely. Break them apart as much as possible.
- Continuously update documentation. Be sure that supporting documentation for users is coincidentally updated to accommodate new changes. You may have to track the areas where the documentation will impact. Ensure there is congruence across the instructions.
- Spiral in. It’s easy to allow feature creep and added niceties. But limit this. The goal is to launch. Create a parking lot instead where you can park future requests. This keeps the project on focus.
Again, the goal is to ship with speed and gain accuracy by collaboration and quick cycles.
The important thing is to remove the expectation of perfection and ensure everyone is on the same page to help get to the goal of usability and launch through iterative cycles. It’s the best way to combat the uncertainty that exists between the concepts agreed upon and reality.