Mastering Discovery for Clear Product Requirements

Kicking off a new project is an exciting challenge for product and service teams. The discovery process informs teams to effectively scope out requirements, manage expectations, and identify key technologies and initiatives that might be used throughout the project. In this piece, I’ll cover some of my experiences with the discovery process as a designer as well as a few helpful things I have learned along the way. The goal is to help identify some unforeseen aspects that teams might encounter in the discovery phase of a project.

Before the kickoff

Regardless of who the project owner is, it is important for the team to have a general understanding of the overall value and immediacy this project has for customers, company, and co-workers alike. Is this a small project that the team will periodically push forward? What will be the assumed nature of the future working sessions and meetings?

During the Kickoff

The initial kick off meeting will look different across teams, brands, and products, but the goal is consistent — gain alignment on project goals, key stakeholders, timeframe, roles, and next steps. Everyone should walk away with a clear understanding of the high-level risks associated with the project, as well as their involvement and contribution.

If the team is solving a problem, brainstorming methods like affinity mapping, sketching, and reverse engineering will help inform assumptions that can be validated for proof of concept. To innovate new ideas/solutions, simply list out every related idea that you can think of. The caveat: list out three times as many new ideas than you would ever want to. The first 10 ideas are mostly terrible and have been done before to some extent. After an idea dump session, carefully look back over your list, marking off, combining , and building onto these ideas. Discuss the interesting findings with your team and build off of each other’s ideas to inform a hunch. You will find that one or two of these sessions can greatly help overcome creative blocks down the project timeline.

If your team is dealing with too many ideas, a helpful method to discern clarity is write out each idea on sticky notes and place them on a grid. Make the x-axis “cool” and the y-axis “useful. You can then plot each idea and evaluate it.

From here the team can start to draw on common themes and identify the next step to take. Remember to validate your solutions with an outside audience (i.e. customers) before moving forward to the next step. This can be done through interviewing or using questionnaires to gauge out the market needs.

Some questions to ask yourself along the way:

  • What are the three biggest things that will have to happen to make this idea work?
  • What activities have helped me focus on the real problem the product should solve?
  • Do customers want this? Why?
  • Who are the players involved to make this happen from start to finish?
  • What are the goals, signals, and metrics?
  • Who could I speak with that would really help this project?
  • Has the timeline or feature list changed? How does that impact the scope and timeline?

When working on business requirements and Scoping

  • What stage of fidelity are we designing in?
  • What absolutely must get done this week? What are the dependencies?
  • What types of frameworks or diagrams can we apply to navigate ambiguity effectively?
  • What are the milestones? What points can we stop to assess to make sure that the project is headed in the right direction?
  • How will we measure success?

After the kickoff, there’s still a need for planning and constant iteration on the overall project scope. If there are any changes to the project, the entire team should know about them as soon as the occur.

This is part one of a series (hopefully). Stay tuned for more.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.