Community before MVP

You should build your community of users before you build your MVP.

Your software product is only as good as the community that uses and supports it. That’s why building an online community should precede building your software product MVP or even looking for funding.

Think about it this way: your MVP is only a minimum viable product. It’s not going to be perfect. And it’s not going to be successful without a community of users to help you fine-tune it and make it better.

The same goes for funding. Sure, you might be able to get some initial funding to get your MVP off the ground. But if you don’t have a community of users to support and promote your product, you’re not going to be able to sustain that funding.

So how do you build an online community? Start by telling your story. Share your vision for your product and why you’re passionate about it. Then, ask for feedback and input from your potential users. What features would they like to see? What problems are they hoping your product will solve?

Engage with your potential community members on social media, in forums, and in other online places where they congregate. And most importantly, listen to what they have to say. Take their feedback to heart and use it to make your product better.

Building an online community takes time and effort, but it’s worth it. By doing so, you’ll ensure that your MVP is successful and that you have the support you need to keep your product and your business thriving.

Community bootstrapping framework

This is a very basic community bootstrapping framework, but it should help you get started with your own community.

1. Identify where you’ll find your customers. Are there intermediaries or influential actors involved?

You’ll need to identify where your potential customers are congregating, whether that’s online or offline. Are there any intermediaries or influential actors involved? If so, you’ll need to make sure that you have a good relationship with them.

2. What value will you give your customers to interest them in your community?

You’ll need to offer potential customers something of value to get them interested in your community. This could be a discount on your product, exclusive content, or early access to new features.

3. Once they’ve joined your community, how will you engage them, to keep them active?

You’ll need to keep your community members engaged by providing them with interesting content, organizing events, and responding to their questions and concerns.

4. Once you’ve started the relationship with them, how will you capture value i.e. what will you sell them?

Once you’ve built up a relationship with your community members, you can start to capture value by selling them products and services.

Hiring versus recruiting

Some recent hard learnings for me around hiring & recruiting…

When recruiting, minimize false negatives. i.e. rejecting someone you should have sent forward

But when hiring, minimize false positives. i.e. hiring someone you shouldn’t have offered to

Trust when recruiting. Verify when hiring. Mistakes happen when you do the opposite.

(Recruiting = attracting talent, hiring = sending an offer)

We're still a very new profession.

We often forget how incredibly new software engineering is, and that we would benefit greatly from learning from other fields.

I recently met an aspiring junior dev who had been in the US Army for 10 years. You better believe they’ll be bringing very smart, transferable ideas to our industry. We’re lucky they’re interested in software engineering.

This is one of the reasons why I’m excited about coding bootcamps and career-switching junior devs.

Lawyers have more than 2,000 years on us. Soldiers, architects, doctors, accountants and teachers even more so. It would be wise to consider that we barely know what we’re doing. Maybe we should take a page out of other professionals’ books.

Can we learn from other professions how to:

• explain what we do better?
• protect our interests?
• train our students?
• express our value?
• self-regulate?

We'll see.

There was once a wise farmer. One day, her prize horse ran away.

“That’s terrible,” the neighours said. “We’ll see,” the farmer said.

The next day, her prize horse returned with a mate.

“That’s amazing,” the neighours said. “We’ll see,” the farmer said.

The next day, the new horse kicked the farmer’s husband and broke his leg.

“That’s terrible,” the neighours said. “We’ll see,” the farmer said.

The next day, the army announced a draft. The farmer’s husband, being injured, was spared.

“You’re so lucky!” said the neighbours. “How can anyone be so lucky?”

“We’ll see,” replied the farmer, and continued tending her crops.

Code that makes money stinks.

Complaining about code quality is easy. Writing code that turns a profit is infinitely harder.

Your instincts might tell you to clean up technical debt. Or you might want to write a feature, or fix a bug.

But should you do it? Is it worth the expense in terms of dollars? Aesthetics, code quality, feature richness, even reliability are unimportant compared to the bottom line.

Which is exactly why code that makes money stinks. Most of the time, it ain’t worth fixing.

Instead, choose simpler technology that’s easier to manage. Talk to your users. Get involved on the business side. Write less code. You’re not just a coder, you’re a problem solver. So solve problems with your whole skillset. Not just with your programming skills.

You’ll have more fun, write better code, build better products, and make more money.

Responsibility

Programmers don’t just write code. We influence human behaviour and the policies and operations of human organizations.

Each tiny decision made by a programmer — the design of each API interface, class, function, and statement — has holistic effects on the software’s clients, and their clients’ clients. The engineers who built Stripe, Twilio and Algolia influence and decide the business processes of millions of client businesses. Those client businesses, in turn, have their own customers who are impacted by engineering choices made upstream.

Think about the impact of software engineers who create computer operating systems and programming languages. The engineers working on these pieces of software make choices that ripple through the economy. In turn, those ripples move through history.

You wield a lot of power. Use it responsibly.

Push it anyway.

If you’re a developer who is looking for work, you need to treat your LinkedIn like a dealership and your Github like a mechanic shop.

When you walk into a car dealership, everything is spotless clean and polished-down, almost sterile. And that’s how it should be, because the job of the dealership is to help create an environment in which you and your family feel comfortable purchasing a car. Being a clean, welcoming, and neutral place is part of the function of the dealership.

When you walk into a mechanic shop, it’s very clear that you’ve entered a workroom. There are loose parts lying around, stained and well-worn tools, cars that are half-taken-apart, and the smell of sweat and grease in the air. Being clean is a nice bonus, but it isn’t really necessary.

Github is a mechanic shop, not a dealership. I expect to see broken code, half-finished projects, and little fun experiments that you worked on and then abandoned. I want to see you working on your craft on your Github. A pretty Github is a nice-to-have, but an empty Github calendar can be a turn-off.

If you want other software developers to take you seriously, treat your LinkedIn like a dealership and your Github like a mechanic shop. Never the other way around.

Is it broken? Push it anyway. If it’s abandoned, leave it up there. My Github is a graveyard of dead projects.