Balancing discovery and development
In an ideal world, ideas are transformed through discovery and development into desired outcomes and impact. Discovery tests our assumptions and provides a design to move forward with. Development takes this knowledge and delivers it to users. Discovery and development are both delivered by the same cross-functional team, often in parallel. In practice, balancing discovery and development isn’t always easy or a priority.
In my experience, working in startups and technology companies, development didn’t have much involvement with discovery. In fact, in many startup environments, the CEO was the discovery team. Design was a phase that resulted in a Sketch or Photoshop file handed over from a branding and PR agency rather than a continuous process running alongside development.
At worst it was a “build it and they will come” approach. The thing with this approach is that “they” don’t usually “come”. And at best? It was a “build, learn, measure” MVP approach. The problem here is that failing is expensive if you’re building comprehensive solutions, or in the case, your CEO will accept a ropey MVP, the solution won’t scale.
There’s pretty much no analysis in the approaches I’ve described or at least none that was visible to me. Even if the research was carried out, the development team certainly weren’t involved. By the time developers were engaged, a shopping list of features were already defined as a product backlog. The backlog was signed, sealed and ready to be delivered to a deadline. Only the development team have no context of the problem they are solving or why the solution in the backlog is the right one.
In my experience, ego-driven development is a good name for this “just get it done” style.
Discovery phases that last years
I see the opposite problem in many government organisations. Discovery phases that last years and end up being reset and started again due to staff turnover. I’d call this, “analysis paralysis”.
I see similar issues with service design and user research consultancies, they naturally lean towards learning and insights, towards discoveries. Perhaps it’s a hammer and nail type of thing, developers naturally lean towards building while designers and researchers naturally lean towards designing and researching.
Interestingly, the time I see discovery skipped or expedited in government is when a minister has a political reason to push forward. Does that remind you of the startup CEO I described earlier? It does me. Ego-driven development, or perhaps politics-driven? Either way, they aren’t backed by validated learning.
Balancing discovery and development
That’s the problem with spectrums, isn’t it? It’s hard to take a middle path, balance is difficult, you’re more likely to lean one way or the other. There’s no blame in what I’ve illustrated, in fact, heavy discovery can be a good thing, and just getting something shipped can also be a good thing. I’d just say that they aren’t always the best route.
I have seen both startups and government organisations take the middle path and I’ve seen it be massively successful. HMPO’s transformed Passport Renewal service is a simple and easy to use digital journey but they still have a commitment to those digitally excluded by providing assisted-digital and paper-based services. Made Tech’s work with FutureGov and the London Borough of Hackney to deliver new services within Housing are cross-organisational collaborations to be proud of that had service design, user research and technology working hand-in-hand with real users. In the private sector, Spotify has been known for taking software engineering seriously but they put as much effort into design.
I actually feel that team composition can have a big impact. I’ve noticed for example when our engineers are engaged during discovery, there’s a tendency for those discoveries to move into development faster. The engineering know-how gives the rest of the team confidence to move forward. I’ve also seen researchers engaged throughout deliveries who can help give pause to development, to stop and think for a moment, instead of building and building and building.
Perhaps there’s a trick in that? If you look at the teams and consultancies who are more comfortable staying in discovery-mode or if you look at the teams and tech companies I’ve worked in who feel more comfortable building rather than thinking, it’s a lack of the other discipline that’s common. Do you see this in your organisation too?
I’d be interested in the results if you’d ask yourself or your team honestly, how balanced is your approach to discovery and development? Let me know the results on Twitter or by email 🙂
We are hiring! Find out more about a career at Made Tech.