Building software is almost always a longer, more expensive project than people think it will be.
This is especially true for enterprise-grade software, the kind of tool a large company will have custom-built to solve a business problem.
Product discovery is when this all should become apparent.
However, there are too many custom software development agencies that downplay discovery, planning and product roadmapping. They’re too eager to start coding, and it’s only later in the project that their clients come to understand the full scope and cost of the development project.
That’s why the Kingsmen Software team invests lots of time and energy upfront into discovery and product roadmapping. It’s important to us that every stakeholder is in alignment on what the final product will do, and what it will take to get that product built.
Below is a guide to discovery and product roadmapping that’s designed specifically for founders in non-tech verticals. We’ll outline both of these processes and explain how they fit into the larger context of a custom development project.
Development Partners Should Understand Your Business
The business context of a software build is crucial, and not something to be glossed over.
Before a development partner can start mapping features or sketching user stories or even thinking about writing a line of code, their team needs to understand your business, your internal processes, and how the software they’re developing supports these things.
Understanding a client’s business is key for the team that’s going to build the software, says Bill Clerici, CEO and partner at Kingsmen Software. “That team is going to build software differently if they have your business in mind than if they’re just given a set of rote requirements.”
Case in point: A few years ago, we had a client, LoanBoss, who came to us looking for help building a commercial real estate tool. After an initial consultation with us, the client ended up choosing another, less expensive development partner that, we found out later, tried to do a speed run through discovery in planning.
A year later — after months and months of missed deadlines and budget overruns — that client came back to us with a partially working product and a codebase that needed to be unraveled. We spent hours with that client to assess what had gone wrong and where the development project got out of alignment with the client’s actual business goals.
In the end, we came up with a plan and roadmap to get the project back on track. We delivered a final working product on time, exactly as we mapped, and the client was elated. “As an owner, I can't stress enough how great it feels to have total confidence in your software — knowing it's going to work,” LoanBoss Founder and President JP Conklin says.
“Confidence” is a key word here. By having a development partner spend so much time upfront understanding your business needs, you come away from discovery and product roadmapping with confidence in the product that’s going to get built.
What Happens During Discovery
“What do you need to build, and how big does it need to be?” is the essential question discovery seeks to answer.
That’s a surprisingly difficult question to answer, says Greg Hart, CFO and managing partner at Kingsmen Software. This is because product stakeholders aren’t always on the same page when a project kicks off.
Often, we find out that people in an organization want their custom software to accomplish three or four different things, and several conversations are necessary “to get everyone rowing in the same direction,” Greg Hart says.
That’s easier to do when you have a north star in mind. Teresa Torres at Product Talk outlines this idea nicely: “Good product discovery has a simple underlying structure: Start with an outcome, discover opportunities, discover solutions.”
Our discovery process can have several stages. First, we talk with product stakeholders and find ways to agree upon a shared vision, set of goals and set of objectives. It could take several meetings and hours of discussion before everyone gets into alignment on these things.
“Product discovery involves multiple stakeholders, such as product managers, designers, developers, and marketers,” James Larson at UsabilityHub writes.
“To ensure that everyone is aligned with the product vision and goals, get these teams involved early in the discovery process. By getting different perspectives in the room early, you can also spot potential roadblocks, align on priorities, and ensure that everyone is working toward the same objectives.”
Next, we look at any previous attempts to build such software, as in the LoanBoss example above. When previous builds are attempted, we need to audit internal resources like existing codebases.
From there, we can begin to define the scope of work, the product’s functionality requirements and the sequence for how that work will get done.
And that’s what a product roadmap details.
How We Structure Product Roadmaps
With goals, objectives and priorities set, we can begin to break the work down. Features become timelines become responsibilities.
There are all kinds of tools for doing this. As the Adobe Experience Cloud team notes, a product roadmap will likely include user stories to give the underlying strategy a sequence, timelines to pace work, goals that work can be measured against, and the product features themselves.
It’s important, however, not to get lost in the details that the map provides. Product roadmaps “should be centered around the big picture and problems to solve, not solutions to those problems,” writes Hannah Clark, editor at The Product Manager.
“It’s very easy to fall into a trap of creating a roadmap that’s solely focused on new features and when they’ll be delivered because that’s usually what makes stakeholders most comfortable. However, it removes autonomy from the team to find solutions to the problems that are outside of previously defined solutions.”
As Thiago Müller at Product Coalition writes, a product roadmap organizes all of those tasks and sprints into a larger whole. “[I]t is paramount to know that features and deliverables are related to a bigger product and company vision. Giving people a desired condition instead of a desired path creates a favorable environment for creativity, innovation and collaboration.”
This is why our roadmaps tend to look different from what other development agencies put together. We don’t map down to the task level. Instead, we map capabilities, then features, then functions. At that point, we have enough detail that we can plan work for several two-week iterations.
That’s an important unit of time for us because, in our software-delivery-as-a-service model, we ship code at the end of every two weeks.
To learn more about how our distinct and thorough approaches to discovery and roadmapping bring business goals and software development into alignment, speak to a consultant today.
Images used under license from Shutterstock.com.