There are many ways of approaching a software development build and each approach has value but one thing you can’t do enough of is preparation and pre-work. Many great Applications start their lives as a result of those ‘eureka’ moments or sudden epiphany’s. Naturally there’s a great deal of excitement and urgency to get moving attached to those ideas. But instead of jumping right into a development build, it’s worth spending some time understanding exactly what it is you want to achieve with your project before you actually spend any of your budget. In our Way of Working we call this part of the process the Brief.

What is the Brief process?

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 product success specialist with years of experience in human centered design and user experience design principles. During the course of a 2 hour discussion we look to gain an understanding not only of 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?

Focus on the problem

And the solution will come as a natural consequence. Sounds like a no brainer right? But there are plenty of examples of bad builds that never took the time to truly and with careful thought consider this question and arrive at an answer. There could be any number of reasons why this didn't happen; pure undiluted excitement and an urge to just get the product out there could be one. Inexperience with software development could be another. The former is understandable, the motivation to create a new business or streamline an existing one through software is exciting and you want to see it come to fruition. The latter comes down to the development agency you select and how willing they are to guide you.

The risk of not understanding the problem is that when you start the scope phase there is a lack of clarity around what the team is actually aiming to do. This can lead to lost time and left unaddressed can result in a missed opportunity with a build that never quite hits the mark.

The way we resolve this is to undertake a problem statement discovery exercise as part of the initial Brief meeting. Once we have heard about your idea and discussed your goals and success metrics we can then take this information and focus in on what the real, tangible and compelling problem is that you're looking to solve for your users. Then, if you choose to move into Scope, the team can use this problem statement 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?

The importance of trust

An often overlooked but vitally important component of a software development build is trust between the product owner and the development team. There are many up's and down's on the journey of taking an idea from concept to reality and unforeseeable technical challenges appear when you least expect them. If you've developed before you will be familiar with this reality but if not, this can come as something of a surprise. When this happens, your 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 Brief 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 Brief is your chance to sound us out.

Is there 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.

The Brief document

As mentioned earlier in this blog, our Brief meetings normally run for about 2 hours and are very much a two way conversation. Yes, there are some slides we run through but we definitely try to avoid the dreaded 'death by PowerPoint' scenario!

As an output of that discussion we create and share with you a Brief Delivery presentation which we will review together. After the Brief Delivery meeting, a soft copy of that presentation is sent to you in PDF format which you can use for internal dissemination or share with potential investors to give them a greater understanding of the problem you are looking to solve and the benefit this will bring to end users as well as your goals and success metrics. If you're at an early stage in the capital raising this document can prove to be very important item in your prospectus.

Pre-Brief checklist

Are you ready for Brief? 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 AI or AR
• Who your primary users are likely to be
• What their main pain points are
• Who the project stakeholders are (and bring them to the Brief meeting)
• Any budget constraints that you might have.