The software industry is a peculiar beast. I’m not sure we can call it ‘young’ any more, at times it still feels like we’re in this awkward adolescent stage, still grappling with the best way to carry out the most fundamental parts of our work. Failure rates in IT projects remain high with Gartner reporting that 75% of ERP projects fail and McKinsey reporting that only 30% of digital transformation projects result in improved performance.
The pace of technological advancement is obviously a huge factor. Each year brings a ‘new and shiny’, along with a wave of hype that forces us to adapt—AI being the obvious recent example. Ordinary businesses are reaching to software companies like ours to help them incorporate AI into their roadmaps without really understanding why they should. Our response to these enquiries is always the same:
Start with discovery
If you google “software discovery process” you’ll see plenty of articles describing ideal, but often different, processes. Process is clearly important but it doesn’t guarantee success. The key lies in adopting a mindset of continual exploration of the problem without getting attached to a particular solution and is a much more effective way to start than a list of requirements.
For instance, we recently embarked on a project for a large client who had already undergone an extensive and costly discovery process with another company. Despite the substantial effort and output, the focus was too much on capturing requirements rather than exploring the problem and potential innovations. Too often, companies focus more on the artefacts produced during discovery, rather than the outcomes and insights it’s meant to deliver. Discovery won’t completely reduce risk, nothing will, but it should provide a level of validation that your approach is feasible, viable and desirable.
Find your why
In my experience teams spend way too much time in the solution space and nowhere near enough in the problem space. People get attached to their first idea and stick to it resolutely as if it’s the only way to solve their particular problem.
The “Five Whys” is a simple but powerful exercise to help you get past the obvious symptoms of a problem, allowing you to dig deeper into the root cause and allow more innovative solutions to surface. For example:
Our team has released a redesigned onboarding flow that is broken into multiple steps rather than single form. Since going live we’ve noticed a drop in the conversion rate and more users are now skipping the onboarding.
- Why are customers skipping the onboarding flow? – Because they don’t see the value in it
- Why don’t they see the value in it? – Because we didn’t validate it with our target customers
- Why didn’t we validate it with our target customers? – Because we didn’t have time in this sprint
- Why didn’t we have time? – Because our sprints are focused on speed of delivery rather than user research
- Why are our agile sprints focused on speed of delivery rather than user research – Because our team feels pressure to hit development milestones over user value
The root cause in this instance is a misalignment in how we measure success, prioritising speed over quality. By shining a light on each layer of the problem, we can decide where we want to intervene. We might choose to address the deeper cultural issue by reviewing how we incentivise our development teams. Regardless of what layer we choose to focus on, this exercise ensures that we make a conscious decision about which ‘why’ we want to solve the problem for.
Involve the right people at the right time
Two key cohorts that need to be brought along on the journey of discovery.
- Internal stakeholders – Anyone with input and influence in the project
- Customers/end users – Those who will actually use the product
Failure to involve the right stakeholders, especially those with influence, can completely derail projects when these folks start to provide feedback. Sometimes, carefully considered decisions are overruled easily by someone with more authority who feels they need to contribute late in the project.
Equally dangerous is failing to involve customers and end users. Without their input at all stages, you’re almost guaranteeing a level of friction in the end product. Especially when it comes to effective user experience design. The G2 state of software survey in 2019 showed that more than half of employees are unhappy at work because of the software they use and a quarter even considered leaving for the same reason.
Create prototypes and test them
The aim of discovery should be to decrease uncertainty. Software projects are inherently full of unknowns, even the best-laid plans can change dramatically once real users get their hands on the product. One of the best ways to generate signals you’re going in the right direction is through prototyping. A “good enough” prototype, tested with real users, will provide many more actionable insights than any amount of research can.
While I’m not a huge fan of the Silicon Valley mantra ”fail early, fail fast”, it’s obviously much cheaper to fail during the prototyping phase than in full development. That’s why I recommend treating your ideas as hypotheses to validate through user testing, rather than fixed solutions that are hard to change.
Don’t stop discovering
We often use a “building” analogy when talking about software, but I think it’s more useful to think of software like a garden. Software should evolve, adapt and grow over time, well beyond the initial launch and we must plan every season for that inevitable change to happen.
Completing an initial discovery phase is a great way to lay a strong foundation but once development commences it’s critical to continue to discover, learn and adapt with the same mindset of exploration if you want to create software that hits that sweet spot between feasibility, viability and desirability.
Ultimately, there just isn’t a universally established industry process for software discovery, and that’s ok. The variability in software projects is huge and we need the flexibility to stay lean and agile in an ever changing landscape. If you approach discovery with an explorer’s mindset, I promise you’ll be in a far better position to succeed. It’s not a silver bullet but it’s as close as you can get.
If you’d like to arrange a chat, email info@gcdtech.com, or call us on +442838341205.
Greg Dalrymple
Head of Design
GCD
