De-Risking Software Series – #1 Discovery Sessions

In this series on de-risking software projects, I want to share the tactics and strategies that I’ve learnt in the 8 years that I’ve been building software.

In this first article, I want to explain the concept of “discovery sessions” and how it’s a game-changer for software and app projects.

When I work with a new client, I ALWAYS start the process with a “Discovery Session”.

This simple 2-hour to half-day session unveils:

  • What’s truly required in your project
  • Any hidden risks that might be lurking beneath the surface
  • The scaffold for what will soon be the project’s scope of works
  • The technical requirements of the project, helping you decide what tools to use to build your project (and therefore what developer you need).

It’s one of the biggest “success levers” that you can leverage for your own project and in this email, I want to explain how you can run your own discovery session without having me in the same room.

Step #1 – Set The Scene

To run a great discovery session, you need a few things:

  • One or two key people from the team building the project. This will likely be you and someone else from your business or a family member.
  • A tech person who understands product development (optional – read to the end of this email to see how you can make this happen)
  • A whiteboard, large sheets of paper or a blank wall with sticky notes.

There is HUGE value in having a product-minded tech person in the room for this process, but you can still learn a lot by running this process with an internal team only.

Once you have the above essentials, you need to set aside some time to run through the process.
You need at least 2 hours or more depending on the complexity of the project and you want a quiet room where you won’t be disturbed for the time you’re there.

Now that the scene is set for our discovery session, it’s time to get to work.

Step #2 – Start With Users

By the end of your discovery session, you want to have the following:

  • A clear understanding of who your users are for your product
  • A list of features that must be created for each of those users
  • A scope of works that you can provide to your development team for a quote or development

The best baseline starting point for a discovery session is to simply list out the users you expect to use your software or app with their name written as column headings on your whiteboard.
A classic example of users that you’d expect in business software is:

  • Admin user
  • Staff user
  • Client user

These are three different user types that each have unique requirements within an app or software product.

Now that you have a high-level list of users that you anticipate will use your product, you can start mapping out their “Journey” within your app.

  • How do they access the system?
  • Once they have access, what is the first thing that they should see?
  • What is the first thing that they should do?
  • What features or workflows will they be likely to prioritise within your product day to day?
  • How will you encourage your users to continue using your product after their initial access?

Now, this stage of the process should be used as a complete ‘brain dump’ of all of the ways you think the different users will use your product and how they should go about that.

Don’t be too concerned with the “how” just yet, just write everything down for each user.

Step #3 – Flesh Things Out

Now that you have a broad, mostly uncategorised list of features and concepts for your app or software, it’s time to add some structure and prioritisation.

For each idea that you’ve added to the wall, ask yourself:

  • How important is this feature in the hierarchy of the project as a whole?
  • Does something else have to occur in the software BEFORE this feature can work? If so, what?
  • How does this feature make the user’s life better?
  • What does this feature streamline or replace for this user?
  • Can this feature be created in a way that delights the user?
  • How can we reduce the clicks (or friction) that it takes for the user to use this feature?
  • Is this feature CRUCIAL for an initial release? If not, when should it be included? Does it need to be included at all?

If you’re the visual type, you can ‘tag’ each feature on your wall with a small coloured circle sticker to demonstrate which features are crucial and should be prioritised and which could be part of a future stage of work.

When thinking through the above questions for your app or software, don’t get caught in the weeds or try to perfectly map everything out.

The purpose of these questions is simply to get your brain working and thinking through the possibilities and the user context of your application.

If, during the process of working through these questions, another new feature pops up, simply attach it to the wall.

Step #4 – Translate To A Scope

Once the above steps are finished, you’re going to have a “spaghetti visual” of your project and the majority of it’s moving parts.

This is the perfect starting point for your project’s scope of works.

I’ll discuss the importance of a rock-solid scope of works for your software project in a future email, but just know that without a very detailed scope of works, you’re starting your project from an extremely unstable foundation.

To translate your Discovery Session’s wall of features to a scope of works, do the following:

  1. Create a document on your computer with headings for each of the users that you’ve found during your discovery process.
  2. For each of those users, start writing down the features that must be created with a simple format of “As a [user type], I can [feature] so that I can [goal].” An example could be, “As a client user, I can log in using an email and password so that I can access my client dashboard”. This format standardises the features and makes them very easy to understand.
  3. Try to create a hierarchy of importance for each user in the user stories so that they’re easier to understand in the future. For example, once the user logs in, what will they want to do next? What then? What then?

Ideally, your scope of works document will be focused on a single stage of work (likely the initial release) but if you’re unsure of how to stage your project, a “complete” scope of works is still a very valuable asset for your future development team.

By the end of this process, you’ve created an incredibly stable foundation for your project now and in the future, and you’ve immediately reduced the risk of your project failing because of the clarity you’ve created.

Early Discovery, Consistent Wins

Software and app projects get harder (and more expensive) to change as time goes on so uncovering requirements and how those requirements work within the context of each different user is invaluable.

Do yourself a huge favour and go through this process for your own project!

If you have any questions about this process or about your own software project, simply contact the Flow team with our contact form online.

Leave a Reply