Continuous Inquiry: Build High-ROI Software by Asking the Right Questions

The software project started off so well. A team of skilled and experienced developers, designers, and project managers was assembled. A collaborative design phase yielded comprehensive wireframes and high-fidelity designs that everyone loved. The developers knew exactly what to build. Regular reviews kept development on track.

But over the course of the project’s timeline, things started going off the rails.

A few unanticipated complexities and technical constraints popped up, a couple of additional features were added midway through, and some seemingly arbitrary changes were made towards the end. The team complied and powered through all these changes, but eventually, this A-team of software engineers was simply slogging through to the finish line.

Then finally, months later, their project was released—to silence.

Very few users seemed interested in the software. Those who did use it complained about various issues. It had several interesting features—exactly what the stakeholders requested—but the users didn’t utilize them as intended. Ultimately, the software simply didn’t see the ROI that was expected.

Sadly, this is a common scenario—software projects face a surprisingly high failure rate. A recent study found that over 30% of projects are canceled before completion, while over half exceed their budgets by 189%. There are many reasons why a project might fail, but these points of failure all expose a larger underlying problem: people stopped asking the right questions, or they never asked them to begin with.

Failure—The Consequence of Questions Never Asked

Most software teams ask at least some questions in the beginning stages of a project. Initially, there’s a large intake meeting with a focus on requirements. Stakeholders work with designers on the overall strategy. Some necessary questions are raised and discussed, leaving developers feeling confident about what’s needed and what it will take to build the final product.

And for a lot of teams—that’s it. One big project kickoff where the bulk of the questions are asked…and then never asked again.

The problem is that most of the time (or probably all of the time), a software project's scope is not fully known from the beginning. It's inevitable that new features might be needed or that additional data comes forward and requires adjustments. This is a normal aspect of software development. However, simply tacking on new features mid-development or allowing changes to seep into the project unchallenged are sure ways for software to fail.

So how does a team handle these realities of software development without slowing down or affecting ROI? How do you ensure you're building the right thing (and the right thing within the right thing)?

Questions. Questions are the answer.

Continuous Inquiry: The Answer Is the Questions

Similar to Continuous Improvement (a core tenet of Kaizen) and CI/CD (an approach to releasing software), Continuous Inquiry is a framework for building the right thing the right way, efficiently and at scale through the continued use of specific questions. It’s comprised of six key questions that should be asked throughout the development lifecycle of a product—not just in the beginning.

The six key questions of Continuous Inquiry are:

1. Why should we build it?
2. What does it do?
3. How will it work?
4. How is it doing?
5. How can we improve it?
6. What are we doing?

Each question needs to be analyzed thoughtfully and realistically using available data, both in the beginning of a project and throughout, as every new feature and change is considered. These questions are designed to address everything from high-level strategic concerns to granular implementation details.

Tools and activities are available to help teams answer each question, ranging from a simple conversation to a multi-day workshop.

The 6 Key Questions and When to Ask Them

Continuous Inquiry means just that—the questions should be asked continually throughout the project. There is no limit to the number of times these questions can be asked, nor should there be. Ask them during the beginning, middle, and end of a project. Ask them when new features are requested, when unexpected challenges arise, when project parameters change, or when new user feedback is acquired. Ask them in any order that makes sense; there’s no need for a strictly linear approach (although it often happens that way).

1. Why should we build it?

This may be an obvious question to ask at the beginning of a project—but its value doesn’t stop there. Once you enter “the middle” of development, stakeholders often request additional features, assuming they can simply be tacked on to what’s already being built without any harm.

That assumption is a dangerous one because a feature's success depends on many factors. Poorly thought-out additions can send deadly shockwaves through the whole product. But often, unanticipated features that present themselves throughout development get treated just like Jira tickets to be closed, adding countless additional hours to the project’s timeline.

So instead of developers being unquestioning order-takers, new feature requests should be challenged objectively, using this question. Just because stakeholders request a new feature or functionality doesn’t mean it is wise or logical to build it.

One method to answer “Why should we build it?” is to conduct a pre-mortem session. This session involves brainstorming what could go wrong with a new feature before it happens—how it could affect the entire system and its users, or the project budget and timeline. The insights gained from a pre-mortem can prove invaluable in the Continuous Inquiry framework, helping your team to decide whether or not a feature is worth pursuing at all. Some features may be valuable but aren’t immediately necessary, so these can be tabled until a more appropriate release or phase of the project.

2. What does it do?

Assuming that you’ve decided a new feature is indeed worth pursuing, “What does it do?” is the next logical question to ask in the Continuous Inquiry process. (At the same time, the answer to this question may also be a key component of answering “Why should we build it?”, further proving that these questions are not always asked sequentially.)

This question addresses the practical value of the proposed feature. How will it help users? What problem will it solve for them? Is there a component to the feature that needs to be included to effectively address the concerns raised in the “Why should we build it?” pre-mortem session?

3. How will it work?

“How will it work?” addresses the more practical applications of the requested feature and is best answered through wireframes, prototype designs, or a detailed, documented explanation. The designers and/or developers research a few approaches and document which one they recommend.

4. How is it doing?

Data collection is the best way to answer “How is it doing?” because it relies on concrete facts instead of assumptions, biases, and opinions. But, how do you collect data, and which data do you collect? Building data collection directly into your software from the beginning is the most effective way to ensure you get your answer to this question as soon as possible.

Addressing this question early in your Continuous Inquiry process may not provide the answer from the beginning, but you’ll be able to understand and prepare for how you’ll get the answer.

5. How can we improve it?

At any point in the software’s lifecycle, you may uncover opportunities for refinement—maybe through user feedback, insights from data collection, or new business requirements. One way to make sure these moments for improvement aren’t overlooked is to schedule a dedicated check-in or retrospective session three months in advance to answer “How can we improve it?” Write the agenda together as a team ahead of time so that all can have the time to analyze the discussion points and prepare their thoughts.

Conducting an impact map session will also help brainstorm ideas for improvement and get you closer to your strategic goals. These ideas can then be subjected to the same questions of Continuous Inquiry to ensure they will work as intended and obtain the desired results.

6. What are we doing?

A common cause of frustration between stakeholders and software creators is miscommunication and unmet expectations, especially when project parameters change. New features or solutions may add additional, unexpected time to the project timeline. Answering this question can help bridge that gap and ensure everyone is on the same page.

Throughout the new feature’s Continuous Inquiry process, an updated and easily accessible timeline should be shared with everyone who needs to see it. Document the agreed-upon changes and clearly explain the impact on the original timeline. This answers “What are we doing?” to stakeholders as well as fellow team members working on the project, keeping everyone’s expectations aligned.

Why the “Right” Software May Surprise You

Some teams start a project thinking they need to build a fully custom app to meet the needs of their users. Their original concept may be loaded with sophisticated features. But after working with a team that utilizes the Continuous Inquiry framework, they may discover that their needs can be met with something far simpler—and more cost-effective.

When the Continuous Inquiry framework is in the driver’s seat, some features don’t make it into the final product, others change drastically, while others are refined. Either way, asking these key questions will ensure that your ROI is maximized and the overall project goal remains your north star.

Change is inevitable, but the Continuous Inquiry process makes it possible to navigate changes with clarity and purpose, giving your project the highest chance of success.