In software development, Product Discovery phases are meant to establish a bridge between an entrepreneur’s vision of a digital product and a technical specification that may serve as blueprint for a team of developers to build such system. Building that bridge typically involves, among other things, a number of information-gathering sessions, ideally with a whiteboard, where key actors are interviewed to elicit the requirements and expectations around the piece of software to be built.
The following are a series of trigger questions for discovery sessions, meant to drive the conversation and make sure that all bases are covered. It’s not by any means complete, but it should provide a decent starting point if you are trying to go through a discovery phase, be it as a software consultant/contractor, or as a client (if your contractor is good, you should be asked these questions).
Context & Motivation
It’s key to gain as much context as possible and gain an understanding of the driving forces for a project. Always start with WHY.
- Why does the client want to build this?
- What change are they trying to drive with it?
- What are they trying to achieve?
- Who is the target audience?
- Who are the champions of this initiative within the organization?
- What’s the expected outcome?
- Who benefits from driving this change? Who doesn’t?
- What would success look like?
Functional
At this point, you should talk about features and priorities. We tend to rely on the MoSCoW prioritization method, which we find easy to understand and provides a good framework for sifting what’s really important from what’s not.
- What must the system do?
- What should be the main features it should provide?
- What would be the core, absolute must-have features that have to ship in a first release of a v1? What are the shoulds and coulds that may wait for a v1.1 or v2?
Non-Functional
Auth & Security
- Can the system be accessed/used anonymously? Will it require a sign-up?
- Must it integrate with some Identity provider? Which protocol does it use? OAuth, SAML, LDAP?
- Does it require multi-factor authentication?
- Will all users be able to access all features? Are there gonna be roles with different permissions?
Aesthetics & User Experience
- Any guidelines in terms of how it must look & feel?
- Is there a color palette that must be respected?
- What should be the priorities for the UX? For example, to do something fast after a training period, or to be easy to use with no training required at all? Engage the user and become a habit?
- What will be the main channel and format the experience will take place? Desktop? Mobile? in portrait or landscape mode?
- Do you know of another app that would serve as a reference for what should be built?
Accessibility & Localization
- Should the user interface be available in different languages? Which ones?
- Must the app implement any accessibility standards?
- Is the app targeted to any population that may require special access features?
Availability
- Will the system be mission critical?
- What’s the impact of downtime? Can it be tolerated? To what degree?
Scalability
- What’s the estimated volume of users that will be using the system? Average? Maximum?
- How is it expected to fluctuate over time?
Integrations
- Will the system need to integrate with any third party to function?
- Would any of the information displayed have to be retrieved from any other system?
- Would any action within the app trigger anything on another system?
Client Platform
This section makes sense as long as the architecture has a client component.
- What device or platform will the user rely on to access the system? Desktop, Web, Mobile, Tablet, Apple TV App, Watch App? Something else?
- In case it’s mobile, does the app have to be targeted or implemented for iOS, or Android specifically, or both?
Analytics
- What information should the app track regarding the user’s interactions/behaviors?
Legal
- Any considerations regarding the legal framework that rules these types of systems?
- Any considerations regarding the terms of service the user must agree to?
- Any restrictions regarding what licenses and software libraries to use?
- Can the data be hosted in any cloud anywhere? Must it be stored on-premises?
Final Thoughts
The sweet spot for these questions is full-stack app development scenarios, like the ones we typically tackle at OrangeLoops. Other scenarios may require adjustments or a deep dive into some aspects.
The output of product discovery phases should include documentation related to:
- Requirements. In the form of user stories, use cases, or a more formal requirements specification.
- UX Specification. Low fidelity, or ideally high fidelity designs of the system’s user interface, or at least the key parts of it. For instance, in the form of Figma diagrams.
- Software Architecture Documentation, such as a SAD or PRD.
This output can be used in the following ways:
- As the set of instructions for a team of developers to build it.
- As the basis for doing an effort estimation
- As a Request For Proposal (RFP) so that different contractors may bid on the implementation of the system.
What do you think? Would you add any questions? Feel free to contact us for a free consultation if you have a software project in mind and need help getting started!
