KimSia Sim 🇸🇬💻📗

About 5 years ago, I had a major disagreement with a pillar customer, a local office of a MNC.

I wanted them to move to the cloud. They refused and couldn't be more precise why other than claiming, "Security".

I was at their office, pointing at a building outside their windows and said,

"Bank {X} has moved their servers to the cloud. And they are more regulated than your industry. What security concerns do you have that's more stringent than a bank?"

They couldn't answer then. This year, they have changed their mind.

Why?

1. My customers have recently seen their counterparts in other country offices move to the cloud, so they are more comfortable now.

2. The existing on-prem servers we had (yes, they won that argument from 5 years ago) have started to break down.

Seems a waste of time on hindsight, right?

Ideal Customer Doesn't Exist 99% of the Time

The simple lesson I draw is this:

If my customers are super savvy, they wouldn't hire me. So they should be somewhat "dumb".

By "dumb", I mean unsavvy or ignorant. Not stupid.

Like we are all "dumb" to our doctors when we are sick because they are the medical experts, not us.

But, sometimes that ignorance can be counterproductive.

Which is why the ideal customer should be so "dumb" they need you, but not that "dumb" to block you from doing your job well.

Sadly, most of your real-life customers will NOT be in this category.

Reject Customers Whose Ignorance Blocks Your Effectiveness. Not Efficiency

How much "dumbness" or ignorance should you accept from your customers since they are seldom perfect?

Of course, you would still recommend the most effective and efficient course of action because you want to help them save costs.

But when they resist, allow them their way even if the results means a drop in efficiency but not effectiveness. As long as you can still do an effective job for them, so be it.

Only when you're blocked from doing an effective job altogether, do you reject such prospects.

In my example, I had to find workarounds and use some hybrid cloud/on-prem solution. Every time I deploy changes, it was painful for me.

But, I could still be effective and they were (and still are) happy!

What If It Impacts Your Cost Structure?

There will be cases where it's more costly for you to deliver an effective service while accommodating the "dumb" constraints.

What you should do is implement a "dumb" tax.

Say, "I charge ${X} usually. But, if you insist on this constraint, I can still do it at ${X + Y} instead".

${Y} is that "dumb" tax.

Most times, they are happy to pay. If not, you now can walk away.

In conclusion,

• NEVER drop your standards in effectiveness

• ALLOW drops in efficiency due to customer requests

• but ALWAYS charge them a "dumb" tax for it

My gratitude to @ModusEffectivus @PigballerinaYan for reading drafts of this

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

Software developers who want to become solopreneurs because they value the freedom and autonomy.

And, making money is key to that autonomy.

These are 5 different ways for software solopreneurs can make money while staying in software industry based on my experience and observing what others have tried successfully.

These are:

1. Service-based and act as subcontractor to larger software agency

2. Service-based and act as main contractor to non-software agency business customer

3. Code as primary input and Product-based such as SaaS or installable software

4. Software-focused or developer-focused community

5. Content as primary input and Product-based such as courses

I won't cover Community and Courses because both are not using code as primary leverage.

I will write a series of 3 essays documenting the pros and cons of the 3 options for solopreneurs.

Service-Based And Subcontractor to Software Agency

I've never done this before personally but I can easily see many people going for it.

Examples include lemon.io.

This makes sense if you're based in a country where cost of living is way lower and the agency gets clients based in developed countries such as USA. This is arbitrage play.

But, take note, this means the agency takes a cut of what they charge the customers. So, this is the least revenue maximizing.

Of the three options, this has the lowest ceiling in terms of growth in revenue. Of all the three options, this is probably the easiest to start if you're an introvert and don't know how to find customers directly.

And all your time is likely devoted to just one client: the agency. The uncharitable interpretation is you're an employee without employee benefits. Contrast this with the product-based option where any single customer leaving you isn't as bad.

You're NOT building equity with this option.

You're still trading time for money like an employee or a gig economy worker.

I recommend this if you're based in low cost country and you don't know how to source for clients directly. Otherwise, I don't recommend.

If you must take this on based in a developed country, do it as a temporary measure. Once you get your financial footing, quickly move away from this.

Next Option Will Be Covered In Tomorrow's Essay So Follow or Like to Get Notified

I realized if I were to write the other two options here, this will be a ~1k word essay.

So I will break it up into 2 more essays -- each covering one option and publishing them over the next 2 days.

Stay tuned.

The Blind Men and the Elephant parable is a typical situation in my workflow software business.

Literally right now, I'm dealing with such a situation.

I have two different users from the same customer: Felicia of Finance Manager and Patricia of Project Manager telling me conflicting accounts on who should be responsible for updating estimated budget in the vendor quotation system I have built for them.

My job then becomes understanding their partial view of the value stream in order to build a complete picture of how the value stream should look like.

Which in turn informs the system I will build.

In other words, I combine all the blind men's limited description to figure out what the entire elephant should look like.

Users Typically Describe Prominent Stuff

Assuming that different users are describing different and partial aspects of the same bigger whole, I've noticed their descriptions tend to be about prominent things.

Using the analogy of a house, users tend to describe the roof and walls of a house. The things that are visible. They seldom describe the pillars and the foundation.

Similarly, if you try to see a pattern of the blind men's description, it's mostly prominent and obvious parts of the larger elephant.

Imagine the Foundation that Holds All the Prominent Stuff

Now my job now is to imagine what kind of foundational material that contains all the prominent stuff the different users have described.

And in a way that allows these seemingly contradictory viewpoints to co-exist harmoniously.

Foundation doesn't just mean more stuff. It also refers to the structure and arrangement of the individual parts.

How they should be put together to form a coherent whole.

Take Customer Requests Seriously But Not Literally

The users have been doing their jobs longer than I have been building the system for them.

Whatever they have been doing, their partial worldview and workflow works for them. Otherwise, it would have long crumbled. So, I have to take them seriously but not literally.

Knowing the distinction between what's foundational and what's prominent allows me to build a system that serves these disparate interests while maintaining a coherent whole.