3 Crucial Reasons for a Project Discovery Session

Why have a Discovery session?

Software development is a creative art not a science and, as such, there is more than one way to approach a software development build. Each approach likely has value and eventually through scoping and discussion with your development team you’ll settle on one. Many great applications started their lives as a result of ‘eureka’ moments or random shower thoughts and naturally there’s a great deal of excitement and urgency to get moving attached to those ideas. But before you can run, you need to learn to walk and the one thing you can’t do enough of is preparation and pre-work. Instead of jumping right into scoping a development build, it’s worth spending some time understanding exactly what it is you want to achieve with your project before you spend any of your budget. In the Geekseat client engagement journey we call this part of the process Discovery, other developers will have their own version.

What is Discovery?

Before you commit to spending valuable budget scoping your project, there is a great deal of value to be derived by taking the time to unpack your concept – at a high level – with a core team of suitably qualified and skilled people with years of experience in understanding the business drivers, design, development, and monetisation of apps. During the course of a 2-hour discussion we look to understand not only what you’re aiming to achieve as a long-term goal and how you will measure success, but just as importantly what your first market release, your MVP (Minimum Viable Product), will help your end users to do. In other words;

What is the problem you are looking to solve?

Reason 1. Articulate the problem

Articulating the problem and the solution will come as a natural consequence. Sounds like a no brainer, right? Well not exactly, there are plenty of examples of bad software builds where no one took the time to truly and with careful thought explore the question ‘what is the actual problem this app is looking to solve’ and arrive at an answer. There could be any number of reasons why this didn’t happen; natural excitement and an urge to just get the product out there could be one reason, inexperience with software development and a lack of professional advice could be another. The former is completely understandable, you’ve had an awesome idea and you want to see it come to fruition, The latter is no one’s fault and we get that too. The issue with not having a clear understanding of the problem you’re looking to solve is that when you start the scope phase of the project, there is a lack of clarity around what the team is aiming to do. This can lead to lost time and if left unaddressed can result in a missed opportunity with a build that never quite hits the mark.

The way we resolve this during the Discovery meeting is to ask a number of key, pointed questions about your target users, what they do now and how that will be different if they use your app. When we overlay your goals and success metrics, we can then take this information and focus in on what the real, tangible, and compelling problem that you’re looking to solve for your users and articulate it in a clearly understandable sentence. When you move into the scope phase of your project, the team can use this articulated problem as a guiding principle against which any proposed functional ideas or concepts can be measured. If a function isn’t helping to solve the problem, should it be included in the MVP?

Reason 2. Develop trust

An often overlooked but vitally important component of a software development build is trust between the client and the development team.

As stated at the beginning of this post, software development is not a science and there are many ups and downs on the journey of taking your idea from concept to reality. It is impossible to predict every technical challenge that may present itself no matter how skilled and experienced your developers may be. Unforeseeable technical issues appear when you least expect them and sometimes means a client is required to make hard decisions. If you’ve developed before you will be familiar with this reality, but if not, this can come as something of a surprise. When it does happen, a good development team will offer suggestions and discuss options of how you can look to address these issues and you need to trust that the advice they are giving you comes from the right place.

Use the Discovery process to meet members of the team and get a feel for who they are and how well you feel you would be able to work with them. Does your culture fit our culture? Are you getting the right vibe? It’s always better to walk away before any commercial contracts have been put in place and the Discovery meeting is your chance to feel your developers out.

Reason 3. Understand the technical fit

This one’s on us! We are all about transparency and would prefer to flag potential challenges right up front so our clients can make informed decisions. Understanding the major elements of your project will allow us to make a determination as to the technical fit between what you want, and our in-house skill set. If there is a mismatch, we will be forthright and tell you up front. This saves everyone time and means that there are no nasty surprises for you as you move your project forward.

It is not in anyone’s interest for us to take on a development for which we don’t have the right in house skills. We do not outsource to third party’s so inevitably this would lead to a poor outcome and in our world, we only want happy clients.

The Discovery Review Document

As mentioned earlier in this article, our Discovery meetings normally run to about 2 hours and are very much a two-way conversation. Yes, there are some slides we run through, but we try to avoid the dreaded ‘death by PowerPoint’ scenario!

As an output of that discussion, we create and share with you a Discovery review presentation which we will review together. After the Discovery review meeting, a soft copy of that presentation is sent to you in .PDF format which you can use for internal dissemination. You might also want to share it with potential investors to give them a greater understanding of the problem you are looking to solve, the benefit this will bring to the target users and your goals and success metrics. If you’re at an early stage in the capital raising journey, this document can prove to be very important component in your prospectus.

Pre-Discovery Checklist

Are you ready to have a Discovery session? If so, here’s a few things you might want to think about and be ready to discuss in the meeting;

• Your timelines for starting and finishing development
• Any non-standard technical requirements like Artificial Intelligence or Augmented Reality
• Who your primary users are likely to be
• What their main pain points are
• Who the project stakeholders are (and add them to the Discovery meeting if possible)
• Any budget constraints that you might have