I recently read a fantastic essay by Alexis Lloyd titled “Design process for the messy in-between.” Towards the end of the essay, Alexis suggests that not everything has to be perfect the first time:
Constraints mean that we almost always have to pick things that aren’t going to get as much love and attention as we would ideally like. Can a feature be removed for launch, or is there a scaled-down MVP of that feature that will suffice for now? Which user group has to have their needs deeply met for success? Can other groups’ needs come later? It’s hard not to want everything to be perfect, but knowing what truly has to be perfect can help in focusing limited resources on the right things.
This approach — being mindful about the flexible standards of ‘ready to ship’ — is one I champion. But in many teams, it’s met with resignation. Product managers, stakeholders, designers, and engineers are skeptical. The most common response to “We’ll fix it later” is “We probably won’t.”
I have a hard time overcoming these doubts. Why do teams (especially long-tenured ones) bristle at the ship-then-improve approach? Why don’t stakeholders believe us when we say that this is the right way to build?
It’s hard to love imperfection
I don’t think that the skeptics are wrong. There’s something really uncomfortable about admitting the shortcomings of your own work. As much as I want everyone (especially myself) to spend years in meditation on the impermanent nature of reality, spiritual enlightenment isn’t a requirement for building software.
Besides, skepticism often comes from experience. We’ve all felt the frustration and humiliation of hearing “I’ll get back to you,” but never getting another reply. Teams are asked to compromise daily; promises of “we’ll fix it later” sound really hollow.
I think we all need help getting comfortable with the uncertainty of building software.
Words matter
I’ve always disliked the phrase ‘Minimum Viable Product.’ The word ‘minimum’ is easy to misinterpret as ‘the least effort’. ‘Viable’ is another low bar: viable things aren’t often desirable, and vice versa. I don’t think I’ve ever gotten a user excited by giving them something and calling it a Minimum Viable Product. I don’t think I’d be sad if I never heard ‘MVP’ again.
Why don’t we talk about efficiency? Let’s amplify ‘clever’ and ‘economical’ ideas. Be crafty, focused, and precise. Share the story of Bill Atkinson reporting to his manager that he wrote -2000 Lines of Code. Welcome constraints, and celebrate the tiny patches as much as (if not more than) the marquee releases.
Don’t just make it safe to fail — make it easy to succeed, too
Practically, this adds up to a lot of communication. But this doesn’t have to be hard if you share your goals in the simplest way possilble.
Don’t communicate your goals with high-fidelity mock-ups of what you think your product will look like. These are time-consuming to update and give a false sense of progress. Instead, abstract your product down to the simplest representation possible. Try boxes and arrows.
Don’t communicate your goals with detailed long-term roadmaps. The far future is going to change constantly as you work. Instead, reduce the detail in your plans as they get farther ahead, only defining the very near future in full.
Don’t commit to features. Features are solutions to problems, but they’re seldom the only solution. Instead, commit to solving the underlying problem; if the ‘not-quite-perfect’ result (fewer new features, or none at all) solves the problem, you’ve still succeeded.
Don’t set goals that can’t be measured. When your goals require subjective judgement, you put a lot of responsibility and pressure on one or two key stakeholders to tell you if you’ve succeeded or not. Instead federate the measurement of success with frameworks like OKRs and jobs-to-be-done.
Conclusion
It’s hard to welcome imperfection into the high-stakes design and development process. Product creators experience the pain of removing features, changing priorities, and reducing scope on a daily basis. By focusing on better goal-setting and communication, we can make it much easier to live with the ever-present uncertainty of building digital products.
How do you handle uncertainty? How does your team respond to shifting priorities and goals? As always, let me know via Twitter.