I just got off a call with a fellow Microconf mastermind member. Let's call him Frank.

Frank's a non-technical founder and he outsourced the development work to an agency. Sadly, despite paying a lot of money, the product is still buggy.

In the call I had with him: I gave him two pieces of advice and cover a planning technique I use in my day job called User Story Mapping.

I'm sharing the two pieces of advice here:

Advice 1: You Must Be Your Own Project Manager

I used an analogy: your product is like the interior design of your house. Usually, you would hire a main contractor who then handles the subcontractors: one for tiling, one for doors, etc.

The main contractor makes sure holistically the final product works out and handles the coordination between the various subcontractors.

In other words, the main contractor is like a project manager.

Frank thought the appointed project manager at the agency can play this role. My advice is Frank has to be his own project manager.

The project manager or account manager at the agency typically handles multiple clients and juggles the tasks between multiple developers. They will never be as devoted as you, the customer.

Also, software development is a lot more fragile than interior design renovations. A small change at the feature level can have a far bigger impact at the product level.

You, the solopreneur customer, has to be the one making sure the various features fit together. Making sure the developer executes your vision correctly.

Advice 2: You Must Be Your Own Business Analyst

In enterprise software, a business analyst (BA) is someone who converts the requests of non-technical customer into streamlined and ranked user requirements and specifications that developers can then almost mindlessly follow to generate the code.

You don't have to be technical to do this, though that can definitely help. But you definitely need to invest the time and effort to be good at it.

It's about clarity in thinking and clarity in writing. In that order.

I told Frank, as an example, in my day job of writing workflow software for my customers, I'm both the BA and the developer.

In Frank's case, my suspicion is nobody is doing the BA tasks between him and the people at the agency he hired.

Hence, there's a breakdown in communications. And a failure to meet expectations.

Think in Roles, Not People

In conclusion, there are 5 compulsory roles in software development.

1. Intended Software User who uses the software

2. Visionary Product Owner who decides direction

3. Project Manager who coordinates and plans

4. Business Analyst who translates

5. Developer who codes

In Frank's case, he needs to imagine himself as 1 and play roles 2-4.

I'll cover how I advised Frank to use User Story Mapping to breakdown and plan out the tasks in a future essay.

My gratitude to @ModusEffectivus @bhumiwrites @mikekohl and Sam Evans for reading drafts of this