Discovery: Questions that Bridge a Software Idea to an Actionable Plan

An Article By Nick Walsh // 11.25.2019

Strategy works to find the intersection of desires and constraints. In software terms, that means measuring features against timelines, budgets, and technologies.

In a new product journey, two landmarks carry most of the attention: that initial lightbulb moment where the big idea takes shape, and pressing the proverbial red button to launch it out into the world. Strategic success for a digital product, though, is determined by the steps taken immediately after the idea settles.

Whether we’re starting with a loose problem statement or a requirements document, every project Envy Labs takes on begins with a planning and research phase known as Discovery.

Discovery kicks off — preferably in-person — with a Project Planning Meeting. Beyond giving each team a chance to mingle and chat about the weather, it allows us to ask stakeholders a series of foundational questions. Determining effort and priority can be fragile within a software project (best exemplified by this classic XKCD comic), so we’re looking to draw out hopes, needs, fears, and biases before anything else begins.

The exact questions vary by organization and goals, but these are the most common inclusions.

Uncovering the Project’s Impact

To start, we focus on the overall effort and how it fits into the company at-large.

How long has this idea or initiative been in the works?

From our side of the table, Discovery is catch-up. We’re stepping in to something that was dreamed up over the course of months or years — an idea that impacts teams, changes workflows, brings value to customers, or outright is the company. For our team to share a sense of ownership over the desired results, we want to walk as much of that journey as possible.

What have you attempted already?

Whether it was an internal team, another vendor, or a founder with some technical know-how, we’re usually not the first to take a crack at the problem. Just like the opening question, it’s invaluable to cover some history: What’s worked? What hasn’t worked? We’re looking to amplify, verify, and iterate on the intuition of those who came before us.

Where do you currently hear the most complaints?

Whether the current process includes software or not, what are the primary sources of conflict? If the initial problem statement is symptomatic of a larger issue, it’s time to pair up and track back to the root cause (the right problem). With a fresh perspective, we often have new insights or approaches that haven’t been considered yet.

Which role, team, or customer does this effort stand to help the most?

Which group of people will be impacted most by the result? We need to collectively plan for getting ideas in front of them, gather feedback, and ensure the end product is ultimately helpful. For internal projects, it’s vital to include the end user as a participant in the process. Introducing a surprise workflow change into their day-to-day process invites unnecessary friction against its adoption, and gaining early insights from those most affected helps drive toward success.

What’s on the horizon?

What features or integrations are next on the wishlist? How quickly after the first phase will they become a priority? What’s the long-term plan for this application shaping up to be? Knowing what’s coming plays a huge role in our recommendations around architecture, libraries, and priorities. Software development balances thousands of decisions. Understanding both current and future needs steers many of those choices towards a better outcome.

Objectives and Measuring Success

With everyone settled in to the Q&A, the next stage is also the most important: Exploring success, and measuring if it happened.

How would you prioritize the project’s objectives?

Pairing our initial conversations and research, we’ll lay out the project’s core objectives. Through dot-voting, everyone has a chance to help prioritize the list (6–10 items, with the ability to add write-ins). No pressure; this only sets the stage for all decisions moving forward. Examples have included:

  • Automate a manual process
  • Promote competition or community
  • Avoid disrupting existing workflows
  • Centralize and sanitize data from multiple sources

How would you prioritize features?

Similar to objectives, we’ll scatter high-level features. This time, though, the goal is to have everyone involved arrange them and agree from highest priority to lowest. An example may look something like this:

  • User stats and analysis
  • Payments
  • Team management
  • Administrative reporting

With administrative reporting pulling up the rear, it’s easier for the project team to steer clear of overcommitting time and budget towards it.

What does (measurable) success look like?

Running a project well and having a successful project are two different things. Beyond things like timeline, budget, and features, we need to identify measurable indicators of success. These can include metrics like:

  • Revenue
  • Adoption rate or user counts
  • Process efficiency gains
  • Knowledge transfer (test scores, completion rates)

How do you define failure?

You know your organization, people, and past efforts best: What hidden factors could impact meeting those measurable goals? Is the target team reluctant to add another system to their process? Does someone on the approval chain have a competing opinion?

What does success beyond your wildest dreams look like?

Assuming everything goes right, what does runaway success look like? At a minimum, this is a lot more fun to talk about than the failure question.

Design Guidelines, Inspiration, and Biases

A usable interface is a baseline deliverable, but the accompanying style is subjective. Here, we’re looking to synchronize with existing efforts and uncover biases.

Do you have existing internal brand standards or design systems?

This one’s pretty straightforward: Are there any existing guidelines that should frame our design work? Are we setting or updating the guidelines? We’ll hit our quality bar while making sure the end result meets any acceptance criteria you’re beholden to.

Are there examples, internal or external, of things you like?

What’s out there right now that you wish your product resembled? Have other teams or departments internally produced something impressive? Examples help ensure the approach taken is in the right style neighborhood.

What don’t you like?

Put it all out there. Do you hate orange? Do modals make you irrationally angry? It’s better to make a note now — we’ll only advocate for the opposite if it’s a clear win for your users.

What are the existing standards around responsiveness, compatibility, and accessibility?

We start with a general set of guidelines: WCAG compliance, support for the last few years of browser releases, and responsiveness down to small phone sizes. Each project, though, carries its own special considerations when taking audience data into account — alongside precedents set in a steadily rising number of ADA lawsuits.

Are there differences in preferred or accessible payment methods across your user base? What do data speeds (and costs) look like in the countries you support? Will a high percentage of your core users be trapped on a legacy browser?

Information Architecture and IT Concerns

Libraries and technologies will become important points of exploration later. At this stage, there’s a handful of architecture questions that can dramatically change requirements and the overall approach.

Have you considered internationalization, HIPAA, and/or PCI Compliance?

File these data security and structure questions under easier to start with than add later. We’ve done it. It can be a real mess.

Are there any existing technology restrictions?

We evangelize certain technologies based on the overall scope, but we’re also looking to factor in things like your team, existing products, and future hiring needs. Are there particular software licenses that need to be avoided when evaluating products and libraries?

What are your deployment preferences?

Does your organization have an existing IT team and a preference for how applications are deployed? Is this an intranet-only sort of project? We’re partial to AWS, but adapting to other delivery means is just a matter of preparation.

What is your support strategy?

Finally, but perhaps most importantly: What’s the long-term plan for software support? We’re happy to draft a maintenance agreement, help onboard a new hire, or hand the project off to an internal team. Each carries time, approach, and budget considerations best discussed early.

Kicking off Software Research

Discovery in software development isn’t covered by a meeting or requirements document. Research, communication, and exploration team up to produce a map towards the desired end state.

Of those three components, communication is the flag bearer. We’re catching up on all of the discussions and decisions made before our involvement, then acting as historian moving forward. The questions detailed here are far from exhaustive, but consistently help set new projects up with the right amount of context.