This is often the mantra for startups but its equally applicable to large organisations, traditionally thought of as being slow to change. It's a concept that underpins the Agile approach to development but be aware that this is only an approach and can be used outside of software development.
Having seen the method of 'ship early and ship often' in practice, I've got the following observations.
- Testing a hypothesis by shipping products or new features is time consuming. Frequent and often can be hard to maintain, and there will be failure along the way. That said, failure is part and parcel of this method and is acceptable as long as we learn from it.
- A launch can be hard to abort but being pragmatic, frequent delays are often seen. Even when something is buggy people will still insist on a launch for whatever personal reasons are attached. The idea of delay can be extremely emotive.
- Post launch analysis and interpretation can be difficult. Furthermore, with all the pressure that comes with sprinting to release, appropriate metrics might not be defined.
- Roll back can be hard.
- After successful launch, high fives and champagne often give way to stagnation as the next big thing comes along. Iteration might not always take place.
How can we get the benefits from this approach without the associated problems?
Ideate and prototype
Skip the build and launch and instead, prototype with user research. Do this in a defined time box such as a Scrum sprint and see which ideas are surviving at the end. There some major factors in the successful implementation of this. This phase is called the design sprint.
The right team
Borrowing from scrum, a team of 5 to 12 people in a room, with a blend of designers, product owners, the sponsor, and others such as customer service reps, sales and others who know the business and its operation.
This blend of people can tell you about inefficiencies and operations, customer issues, the high level business vision and of course good design. This should be done in a secluded place away from all distractions. This might be hard to do but are we in it to succeed or to just muddle along while juggling other activities, and in some cases, operational BAU?
Time pressure and a problem
Have a problem ready and close target date. This will create urgency and people will rally around to meet the target. The problem statement should then be tackled, sketching out the user story and how the problem is a problem.
Sketching out the solution may lead to creativity but in a diverse group there may be a tendency towards group think. To avoid this, everyone can sketch out their own ideas individually.
Rather than a discussion where the loudest and most senior often direct the group, the group could judge each idea using coloured stickers to form a heat map of ideas. Maybe some additional criteria could be added too.
Another way could be the use of Liberating Structures and the 1-2-4-ALL method. This also engages everyone in the group and is a way that allows introverts and extroverts to all be involved. It only takes 12 minutes and is easy to do.
- Have 1 minute of silent reflection for everyone in the group in regards to a question that has been asked. Topics to think about could be opportunities for progress. How to handle the situation? What ideas or actions could be developed?
- Work in pairs for 2 minutes, taking the ideas from self reflection.
- Create four groups of up to four people and share ideas, noting similarities and differences for another 4 minutes.
- ALL - For the final 5 minutes, each group can share one important idea.
Point 4 can be repeated as necessary. It might seem a little awkward but it's a liberating way of everyone in the team being able to contribute, and not just the loudest.
Build the prototype and test
We should be able to move from low fidelity (sketches) to high fidelity (screen designs that can be clicked). Once built we should then get some users who fit the target profile and observe them clicking on the prototype. They should also be talking out loud so that we can hear their intention or problems they are experiencing.
What has been learned?
By the end, we should now have the learning needed to iterate with clarity. By using 'design sprints' we reduce the risk in building the wrong thing, get everyone's input, and find that team members are happy because they are being treated respectfully and can genuinely contribute