What’s the value of the Brief process?

SOFTWARE DEVELOPMENT

There are many ways of ap­proach­ing a soft­ware de­vel­op­ment build and each ap­proach has value but one thing you can’t do enough of is prepa­ra­tion and pre-work. Many great Applications start their lives as a re­sult of those ‘eureka’ mo­ments or sud­den epiphany’s. Naturally there’s a great deal of ex­cite­ment and ur­gency to get mov­ing at­tached to those ideas. But in­stead of jump­ing right into a de­vel­op­ment build, it’s worth spend­ing some time un­der­stand­ing ex­actly what it is you want to achieve with your pro­ject be­fore you ac­tu­ally spend any of your bud­get. In our Way of Working we call this part of the process the Brief.

What is the Brief process?

Before you com­mit to spend­ing valu­able bud­get scop­ing your pro­ject, there is a great deal of value to be de­rived by tak­ing the time to un­pack your con­cept — at a high level — with a prod­uct suc­cess spe­cial­ist with years of ex­pe­ri­ence in hu­man cen­tered de­sign and user ex­pe­ri­ence de­sign prin­ci­ples. During the course of a 2 hour dis­cus­sion we look to gain an un­der­stand­ing not only of what you’re aim­ing to achieve as a long term goal and how you will mea­sure suc­cess but just as im­por­tantly what your first mar­ket re­lease, your MVP (Minimum Viable Product), will help your end users to do. In other words;

What is the prob­lem you are look­ing to solve?

Focus on the prob­lem

And the so­lu­tion will come as a nat­ural con­se­quence. Sounds like a no brainer right? But there are plenty of ex­am­ples of bad builds that never took the time to truly and with care­ful thought con­sider this ques­tion and ar­rive at an an­swer. There could be any num­ber of rea­sons why this did­n’t hap­pen; pure undi­luted ex­cite­ment and an urge to just get the prod­uct out there could be one. Inexperience with soft­ware de­vel­op­ment could be an­other. The for­mer is un­der­stand­able, the mo­ti­va­tion to cre­ate a new busi­ness or stream­line an ex­ist­ing one through soft­ware is ex­cit­ing and you want to see it come to fruition. The lat­ter comes down to the de­vel­op­ment agency you se­lect and how will­ing they are to guide you.

The risk of not un­der­stand­ing the prob­lem is that when you start the scope phase there is a lack of clar­ity around what the team is ac­tu­ally aim­ing to do. This can lead to lost time and left un­ad­dressed can re­sult in a missed op­por­tu­nity with a build that never quite hits the mark.

The way we re­solve this is to un­der­take a prob­lem state­ment dis­cov­ery ex­er­cise as part of the ini­tial Brief meet­ing. Once we have heard about your idea and dis­cussed your goals and suc­cess met­rics we can then take this in­for­ma­tion and fo­cus in on what the real, tan­gi­ble and com­pelling prob­lem is that you’re look­ing to solve for your users. Then, if you choose to move into Scope, the team can use this prob­lem state­ment as a guid­ing prin­ci­ple against which any pro­posed func­tional ideas or con­cepts can be mea­sured. If a func­tion is­n’t help­ing to solve the prob­lem, should it be in­cluded in the MVP?

The im­por­tance of trust

An of­ten over­looked but vi­tally im­por­tant com­po­nent of a soft­ware de­vel­op­ment build is trust be­tween the prod­uct owner and the de­vel­op­ment team. There are many up’s and down’s on the jour­ney of tak­ing an idea from con­cept to re­al­ity and un­fore­see­able tech­ni­cal chal­lenges ap­pear when you least ex­pect them. If you’ve de­vel­oped be­fore you will be fa­mil­iar with this re­al­ity but if not, this can come as some­thing of a sur­prise. When this hap­pens, your de­vel­op­ment team will of­fer sug­ges­tions and dis­cuss op­tions of how you can look to ad­dress these is­sues and you need to trust that the ad­vice they are giv­ing you comes from the right place.

Use the Brief process to meet mem­bers 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 cul­ture fit our cul­ture? Are you get­ting the right vibe? It’s al­ways bet­ter to walk away be­fore any com­mer­cial con­tracts have been put in place and the Brief is your chance to sound us out.

Is there tech­ni­cal fit?

This one’s on us! We are all about trans­parency and would pre­fer to flag po­ten­tial chal­lenges right up front so our clients can make in­formed de­ci­sions. Understanding the ma­jor el­e­ments of your pro­ject will al­low us to make a de­ter­mi­na­tion as to the tech­ni­cal fit be­tween what you want, and our in house skill set. If there is a mis­match, we will be forth­right and tell you up front. This saves every­one time and means that there are no nasty sur­prises for you as you move your pro­ject for­ward.

The Brief doc­u­ment

As men­tioned ear­lier in this blog, our Brief meet­ings nor­mally run for about 2 hours and are very much a two way con­ver­sa­tion. Yes, there are some slides we run through but we def­i­nitely try to avoid the dreaded ‘death by PowerPoint’ sce­nario!

As an out­put of that dis­cus­sion we cre­ate and share with you a Brief Delivery pre­sen­ta­tion which we will re­view to­gether. After the Brief Delivery meet­ing, a soft copy of that pre­sen­ta­tion is sent to you in PDF for­mat which you can use for in­ter­nal dis­sem­i­na­tion or share with po­ten­tial in­vestors to give them a greater un­der­stand­ing of the prob­lem you are look­ing to solve and the ben­e­fit this will bring to end users as well as your goals and suc­cess met­rics. If you’re at an early stage in the cap­i­tal rais­ing this doc­u­ment can prove to be very im­por­tant item in your prospec­tus.

Pre-Brief check­list

Are you ready for Brief? If so, here’s a few things you might want to think about and be ready to dis­cuss in the meet­ing;

  • Your time­lines for start­ing and fin­ish­ing de­vel­op­ment
  • Any non-stan­dard tech­ni­cal re­quire­ments like AI or AR
  • Who your pri­mary users are likely to be
  • What their main pain points are
  • Who the pro­ject stake­hold­ers are (and bring them to the Brief meet­ing)
  • Any bud­get con­straints that you might have.

Discover Software
Secrets

ABOUT THE AUTHOR

Blair Williams

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion