Optimizing for Speed Risks Missing the Mark
They’ve always existed, but starting with low code platforms and now vastly accelerating with AI-assisted development, dev shops who are ready, willing, and able to “just build it” are lining up to take your money. To be sure, there are some excellent teams out there whose sole focus is development (and there are many more stinkers). I’m not here to say being focused solely on build is a bad thing. But when the plan is scope > build > ship > repeat, something important is lost. Those companies are inherently optimizing for speed and margin over outcome. If they build the thing you asked for, they’ve done their job. But does that help you achieve your goals?
What gets lost between project kickoff and launch in those scenarios is this: the actual outcomes you’re trying to influence. Suddenly the deciding factor for all decisions is what’s easiest to build, not what advances your goals. As an example, in a prior project we built a relationship model between account owners and users within their organization that made sense to us, but upon closer examination against our client’s roadmap it became clear that this structure wouldn’t support necessary features. Our clients then helped us better understand the reality of the relationships in the context of the system we were building and we found the right path forward. Without a roadmap to check against we wouldn’t have seen this conflict until much later in the project (meaning a feature that didn’t work as needed or costly rework).
Roadmap to Guide Your Way
Presumably you’re building your own product because there’s nothing out there that does exactly what you need (otherwise you’re wasting a lot of time and money). You’ve got a specific vision for what success looks like. You also presumably don’t have the technical ability in house to build this for you. This is exactly why your vision, while a good starting point, is not sufficient to drive development success. You need a partner who can translate your business outcomes into product terms before you can know what to build. It’s a non-obvious critical step that people outside of the Product Design world don’t often consider.
This is the entire point of our Roadmap Workshop. The concept of explore, challenge, refine is not a euphemism for delay. It’s the embodiment of measure twice, cut once. In the workshop, we’ll clarify goals and stakeholders. We’ll speak to your end-users. We’ll map our findings to development opportunities and help you make informed decisions about where we focus our efforts. By the end, we’ll have a plan of action (a roadmap) to guide our development efforts. We’ll know what we’re building, why we’re building it, and how it’ll move you closer to your ultimate goals. Your vision is the deliverable. This way the likelihood of your product achieving success is far higher than if your devs simply built whatever you told them. This isn’t an indictment of your vision, it’s an acknowledgement that software development is a multivariate and complex process that must balance many stakeholders and criteria.
All projects should start with a Roadmap Workshop. It’s a smart investment in ensuring what you build is what will achieve your goals.