Discovery: Can You Answer Software’s Key Kickoff Questions?

Decision paralysis: Software can go any which way, and the question on every founder’s mind is where do we start? You’re balancing the push-and-pull of so many things — building a team, defining sales and marketing, managing funding, picking up dry cleaning, and dozens of other tasks. Tossing the tech on top is overwhelming.

Strategy: It’s a step back, and may feel like a tap on the brakes. Writing code = velocity, right? In practice, software without a bit of planning is an aimless stroll: You won’t wind up in the place you’d pictured.

New applications are big-ticket items, lending a lot of value to anything that can de-risk the whole operation. To that end, strategy acts as a big flowchart for finding a project’s intersection of desires and constraints. It’s looking for:

• History, to avoid some of that doomed to repeat it stuff
• Objectives, so we can decide what success means
• Guide rails and preferences for both design and development
• Any big unknowns that’ll need further work to define

At Envy Labs, software ideas run through a phase called Discovery (a pretty common title in the biz). The first step? Peppering you with a whole bunch of questions. The list itself will vary by industry, project, goals, and such, but these are the most common inclusions.

Framing a New Software Application’s Impact

To start, let’s talk about the overall effort and where it sits in the industry — the 30,000 foot view before we get in the weeds.

Burning Questions

How long has this whole thing been in the works?

On our side of the table, Discovery is a mini bootcamp. You’ve dreamed this up: An idea with impact, value, and the ability to create change. For our team to share a sense of ownership over the project’s goals, we want to hear all about that journey.

What have you tried so far?

Whether it was an internal team, another vendor, or you’re a founder with some technical chops, we’re usually not the first to take a shot at the problem. Just like the first question, it’s all about history: What’s worked? What didn’t? We’re looking to amplify, verify, and iterate on the intuition of those who came before us.

Where does the current process fall down? What blind spots do competitors have?

What are you changing with this new piece of tech? We’re aiming for the roots of your idea, and everything worth sharing about the current market. This is where our outside perspective can start adding some new insights.

Who will gain the most from the end product?

In the end, who’ll be impacted most? What’s the plan to put ideas in front of them, gather feedback, and make sure we’ve hit the mark?

For internal projects, it’s vital to include your team as a participant. Introducing a surprise change in someone’s day-to-day is a sure way to torpedo adoption — looping them in early promotes ownership of the result.

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? Knowing what’s coming plays a big role in our recommendations around architecture, libraries, and priorities.

Measuring Software’s Eventual Success

With everyone settled into Q&A mode, the next stage is the most important: Exploring success, and measuring if we got there.

Burning Questions

What’s the best order for your objectives?

Pairing our initial conversations and research, we’ll lay out the project’s core objectives. Through dot-voting, everybody 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 include:

• Automate a process that’s been manual up til’ now
• Promote competition or community alongside gamification
• Avoid disrupting an existing application or feature
• Integrate and sanitize previously inaccessible data

How are features prioritized to fit those objectives?

It’s too early to set features in stone, but a quick look at the basics is helpful. We’ll scatter notecard versions of high-level possibilities, then prioritize as a group. That’ll look something like:

• User dashboard
• Payments
• Team management
• Administrative reporting

With administrative reporting pulling up the rear with this hypothetical ranking, it’ll be easier for the project team to steer clear of overcommitting time and budget towards it.

What measurement can we use to figure out if this all worked?

Running a project well and having a successful project are two different things. Beyond stats 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)

What does failure look like?

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? Do any stakeholders have competing opinions? Thinking through the how and why behind potential problems helps mitigate them.

Who could be negatively impacted when this is released?

We’ve progressed beyond the move-fast-break-things phase of startup technology, which adds an ethical pause here. Are there any Waze-esque side effects so far? It’s easier to mitigate potential problems before the toothpaste is out of the tube.

Design Guidelines, Inspiration, and Biases

A usable interface is a baseline deliverable, but the paired style is subjective. Here, we’re looking to match up with existing efforts, uncover biases, and have a little fun with some design-centric exercises.

Burning Questions

What are your current design standards? Want to keep them?

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

What’s out there (internal or external) that you’re a fan of?

Which existing apps match what’s in your head? Have other teams or departments internally produced something impressive? Examples help us find the right neighborhood to start.

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 challenge biases if your users stand to gain something.

Any special considerations for responsiveness, compatibility, or accessibility?

Are there differences in preferred or accessible payment methods across your users? What do data speeds (and costs) look like in applicable countries? Will a high percentage of your core users be trapped on a legacy browser? We start with a general set of guidelines, then expand accessibility and device support from there.

Information Architecture and IT Input

Code comes later. For now, at least, there are a few architecture questions that’ll shape some big technical decisions.

Burning Questions

What’s needed around 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. Trust us, we’ve done both.

Any existing technology restrictions?

We have a few favorite technologies, but we’re also looking to weigh factors like your team, existing products, and future hiring needs. Do you need to own every piece of code, or are open-source licenses okay? Which third-party products do you already subscribe to?

Who’ll own which third-party accounts?

Hosting, version control, and a handful of other services will eventually need setup. Should we create those accounts and transfer them later, or do they already exist?

What will deployment look like?

Does your organization have an existing IT team and a preference for deployments? Is this an intranet-only project? As with underlying tech, we have our favorites here, but it’s important to pull all of the circumstances together.

What will maintenance and future features look like?

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 covered now.

Giving Software its (Best) Start

So, you’ve successfully navigated a bunch of high-level questions. What’s next?

The answers here inform the rest of the strategy phase, but there’s still work to be done: Wireframes, prototypes, scoping, and a number of other planning tasks may get their day in the sun. If you’re trying to get a jump on all of your potential homework, take a peek at our guide to working with an outside firm.

If you’re mulling over an application idea and Discovery sounds like it could fit, we’d love to chat.