Rapid prototyping can be a helpful tool for us as digital project managers to help clients who ask the question; ‘But will this work?’ and ‘How will this work?’ Often the simple, but frustrating answer is simply, ‘We don’t know yet – but let us help you work it out.’ A great way of working it out, and one that’s becoming increasingly popular with agencies and clients is by rapid prototyping -investing a little to make an informed decision on product viability before making any big investments.
Our industry moves at lightning speed, and as a digital project manager, we have to be quick to adapt to new ways of working. A current example of that is rapid prototyping. Nine months ago, I had never worked on a rapid prototyping project and now I’ve just wrapped up my fourth rapid prototyping project to test product viability quickly. So if you haven’t already worked on a rapid prototyping project, I’m in no doubt one is just around the corner for you.
This post explains different routes to exploring product viability and will provide you with some guiding principles to help you manage fast-moving digital or analogue projects with confidence.
But first, what is rapid prototyping?
Rapid prototyping refers to the process applied to building a proof of concept or rapid prototypes. A prototype is good for testing the validity of a concept. It will allow you to develop more features, faster but this is normally at the cost of quality and for this reason, the product will be, for the most part, disposable.
Prototypes come in different shapes and sizes
Although there are various ways you can explore product viability, here are three distinct approaches:
- Proof of concept – A proof of concept is a very lightweight, throwaway demonstrator of the product aimed at testing the idea behind the product before building it.
- Rapid prototype – A rapid prototype is a lightweight first version of the product that can be tested with real users to gain more confidence in the product before the full build.
- Minimum viable product (MVP) – An MVP is the first production-quality version of the product, building up fully working features for the users.
Your confidence in the product should be the main deciding factor for determining which approach to take.
The riskier the idea = the faster you should go.
Some people may say that if an idea is risky then you should spend more time thinking about it before building it. In some ways, they’re right. You can validate a need almost without building anything, There are numerous examples of validation testing which are worth researching.
However, once you know there’s a need, the only way to prove that need’s to build something, release it as quickly as possible in it’s rawest form, get feedback and iterate. We’ve found numerous times that when you’re researching an idea, the customer will inevitably say “I’d buy that” and then when the product ships, the sales don’t shift.
“I would definitely buy that” – 100 people
People who will actually buy it = 10
Jeff Sheldon (@ugmonk) September 1, 2016
Rapid prototyping mitigates risk every time by shortening the feedback loop and ensuring your building a product that’ll sell.
How to know which one is right for you
Prototyping Style | Confidence | How Fake | How Disposable |
---|---|---|---|
Proof of concept | Low | Completely | Completely |
Rapid prototype | Medium | Partly | Partly |
Minimum Viable Product | High | Very little/none | Built to last |
In order to build things quickly, you have to be open to developing new processes and ways of working.
Guiding principles for managing rapid prototyping projects
Working in the ways outlined below requires a new mindset. I’d recommend starting your project with an internal kick-off to run through these principles and explain why they’re important. This will help ensure the whole team is aligned from the start, know what is expected of them and will be aware of where and why the project may differ from what they’re used to.
1. Be prepared to do less
This will probably mean less upfront planning than you’re used to and include being comfortable with having:
- No, or minimal acceptance criteria
- No sub-tasks on stories
- No estimates
What you lose in a rigid process you gain in speed, trust, and communication. Embrace the lack of control.
This principle will remind the whole team that it’s ok to abandon well-known processes at the expense of delivering working software sooner. It’s good to regularly ask yourself and the team “is this the quickest way to do x?”.
2. Show, don’t tell
As you’re doing less up front planning, you’ll be doing more talking and drawing during development. You may want to extend your scrums so you can talk about the feature in a bit more detail before your team starts building it that day. As the saying goes, a picture speaks a thousand words. Sometimes a sketch of the page, a content model or a diagram to show how the system is going to be built is enough to start building and then you can iterate on top of that.
This principle will instill confidence in you and the client, everyone enjoys seeing progress and showing work regularly enables the opportunity for timely feedback, therefore minimising waste.
3. Ask for forgiveness, not permission
With most rigorous software development process, a consensus is key. You want the product owner to sign off on acceptance criteria and as a PM you want to know that you’re team has understood the requirements before writing a line of code.
With rapid prototypes, it’s important that your team feels empowered to just build it to the best of their understanding as it stands, then show their work as quickly as possible, get feedback and iterate.
Getting consensus from the start will slow things down and work is rarely wasted if the team show what they’re working on early and often.
This principle is particularly useful for developers, it puts the onus on them to initially architect and build a feature with little external influence. Often we build too much, over complicate things because we don’t always see the technical complexity involved in our requests, therefore trusting the developers on the team to decide what the most basic implementation is and building that first is a great way to go.
For this to work, it’s essential that your developers have a deep understanding of the project so that they are able make the right decisions for the project and only ever build just enough.
4. Always encourage the team to show what they’re working on (even if it’s ugly)
This process is inspired by the Government Digital Services prototyping principles
Show the thing! No working software = no more money past alpha https://t.co/Jw65kO1u3M WEll done @hmtreasury pic.twitter.com/rJuB9IBShp
Mike Bracken (@MTBracken) April 13, 2014
Typically, we only show clients features when they’re finished. On rapid prototyping projects, it’s important to show it as soon as it’s functional so you can minimize waste, iterate, and pivot if required.
Make it work. Show the thing.
Make it pretty. Show the thing.
Make it scale. Show the thing.
This principle releases team members from feeling like they should only show work when it’s been reviewed by a design or has been fully tested. Celebrate work in progress.
5. Choose physical processes over online ones
In the words of Brett Harned, we manage projects with our minds, not with our tools. Don’t be afraid to abandon your project management tools. Visualize the work, use a physical backlog, stick sketches, user flows, personas on the wall and scrum around it. Refer to it often and encourage people to take ownership of moving cards and celebrating deploying new features. If your client isn’t co-located, photograph and slack everything so they’re not left out.
Trying out a new process can be tricky, visualizing the work is likely to draw out conversations which wouldn’t happen if you were on hangouts looking at a digital board. It will quickly become apparent if a physical card hasn’t been moved for a day or if there is too much WIP. Using physical processes provides an extra layer of transparency which believe me, when everything feels hazy, you’ll be eternally grateful for.
6. Be excellent to each other
It’s natural to feel overwhelmed when you’re trying to embed a new process and way of working, especially when you’re new to it too. Lead with confidence though and encourage the team when they’re struggling. Listen attentively to their concerns and be willing to tweak the process as you go. Make sure the process isn’t putting additional pressure on your team, rapid prototyping is about working smarter not harder.
Depending on the personalities on your team, some team members will embrace this new way of working whilst others might resist it. We all learn at different speeds and each discipline will be tackling different challenges as they adapt to working in a new way. As a PM remain mindful of this and seek to create a supportive and safe environment for the team – sit together, drink tea and check in with everyone regularly to see how they’re getting on.
7. Minimise distractions
It’s sometimes tricky to know as a PM where you can make compromises with a new process and where you should stick to your guns. When it comes to accepting new changes mid-sprint, continue to push back and to say no. It’s important that when a sprint starts, your team are undisrupted, protecting their time is the most valuable thing you can do.
This principle empowers the team to push back on requests. It’s likely that you’ll be running one-week sprints, with such a short window of time, you can’t afford to lose time. Get buy-in from the wider company so people feel able to defer internal meetings or additional responsibilities so they can get their heads down during that period.
Making rapid prototyping work for you
I’ve found this new approach to working extremely rewarding, at times it felt chaotic, messy and out of control. It’s difficult to know where and how much you should deviate from your current process but I’d encourage you to experiment, fail fast and be open with your team about what you need from them.
On occasions, we removed a core part of the process and later reinstated it because it became apparent that I was struggling to manage the project without it. At these points in the project, I made sure I could clearly explain the ramifications of removing this process to the rest of my team. As a team, we would discuss if there was an alternative way for me to gain that information, if we couldn’t find a better solution we would reinstate the process. It’s at times like this where you reap the benefits of building a supportive environment of mutual trust and respect. At every point, we learn, iterate and move on as a whole team.
Credit to Chris Thorpe for these principles, everything I know is because of him.