Discovery: Questions that Bridge a Software Idea to an Actionable Plan
Software projects start with unbound possibility. Infinite paths, competing approaches, and the decision paralysis that comes with finding where to begin.
Strategy finds the intersection of desires and constraints. As a process, it’s become a bit of a buzzword, but as a concept, it’s so foundationally important to big-ticket projects. In software terms, that means measuring features against timelines, budgets, and technologies — like a large collaborative flowchart for a team to navigate.
In a new product journey, two landmarks carry most of the attention:
- The initial lightbulb moment, where a big idea takes shape
- Pressing the proverbial red button to launch it out into the world
For a digital product, though, strategic success is determined by the steps taken immediately after the idea settles.
Whether the starting point is a loose problem statement or a list of requirements, most firms begin projects with a planning and research phase. At Envy Labs — like many other development shops — we call it 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 pepper stakeholders with a series of questions. Sorting effort and priority is tough while building an application, so we’re looking to draw out hopes, needs, fears, and biases as everything spins up.
The exact questions vary by organization, project type, and goals, but let’s run through the most common inclusions.
Uncovering the Project’s Impact
To start, we focus on the overall effort and how it fits into your company — the 30,000 foot view of everything before a deep dive into details.
How long has this idea or initiative been in the works?
For us, Discovery is catch-up. We’re stepping into 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 first question, it’s all about 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? What blind spots do existing products have?
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.
Similarly, if you’re starting completely fresh, what competitors are out in the market? What are they missing?
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 to place 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 gives them some ownership over the solution.
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 can help avoid rewriting code later.
Objectives and Measuring Success
With everyone settled in to the Q&A, the next stage is the most important: Exploring success, and measuring if it happened. As we’ve touched on in other articles, getting this right is also vitally important to our side of the table.
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
- Team management
- Administrative reporting
With administrative reporting pulling up the rear with this hypothetical ranking, 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:
- 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? Thinking through the how and why behind potential problems helps mitigate them.
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 good chaser after that 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, uncover biases, and have a little fun with some design-centric exercises.
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 tied 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 approach.
Have you considered internationalization, HIPAA, and/or PCI Compliance?
These data security and structure questions all fall under the category of easier to start with than add later. Take our word for it.
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 Amazon Web Services (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 historians moving forward. The questions detailed here are far from exhaustive, but consistently help set new projects up with the right foundational context.
If you’re mulling over an application idea and Discovery sounds like a positive first step, we’d love to chat.
From day one, you need to be sure you and your software development partner are speaking the same language. Find out how to bridge costly communication problems.