Indie Hacker vs. Product Team

5 Rules for Indie Hackers

Someone asked me recently:

What do you think is the difference between a Product Manager & an Indie Hacker?

According to George Leonard’s “Mastery”,

“The Hacker has a different attitude. After sort of getting the hang of a thing, he or she is willing to stay on the plateau indefinitely. He doesn’t mind skipping stages essential to the development of mastery if he can just go out and hack around with fellow hackers.”

The Indie Hacker is a Product Team consisting of a (Senior) Product Manager, a Designer, a Marketer & an Engineer.

They are just one and the same person.

How do these roles manifest?

What are some of the rules we can distill?

Would this fit you?

The Indie Hacker is a Senior Product Manager

Earlier, I wrote about How To Become a Senior Product Manager.

A Senior Product Manager will do market research & discover the market opportunity for better remote working headphones while speaking to customers and partners during their day-to-day work. They’ll create a product strategy to win the market, analyze which audience to address first, and convince executives to spin up a new team. Then, they’ll also interview customers, test prototypes, and work closely with marketing to successfully launch the new product.

Senior PM finds new opportunities and rallies resources to jump on those opportunities.

They have great strategic & entrepreneurial skills.

It’s the closest to a solopreneur role inside the company.

Indie Hackers are almost by definition solopreneurs and most of the the time, it’s by design.

In stories of Indie Hackers, the narrative of “getting tired of the corporate world” is prevalent.

They don’t want to have to check with anyone about whether a problem is worth solving or not.

They don’t need someone to tell them how to solve it.

They don’t want to sit in meetings with those who hold budget (or worse, with those who don’t hold any budget, but still want to have a say).

They don’t necessarily need to align with any company or product strategy.

It’s a form of freedom.

The big trade-off is that if the Indie Hacker is right or wrong, it’s their money on the table.

And while I believe that this “skin in the game” is 10x better for accountability & pivoting sooner, you do need (a) funds and/or (b) craftiness.

Rule #1 — Have funds and/or be crafty.

The difference is in the sequence of attributes that play a bigger role at first.

An Indie Hacker can be an Indie Hacker even if they have a poor understanding of the market, the customer problem and don’t have a way to rally the troops.

A Senior PM doesn’t have this luxury, or they wouldn’t be in the role that they were in.

But over time, as the Indie Hacker runs out of funds (learns) and/or applies his craftiness to the problem, this difference disappears.

The Indie Hacker is a Designer

“Every great entrepreneur is first and foremost a designer.” — Peter Thiel, “Zero To One”

Design is a loaded term.

Some say designers can do everything: research, front-end engineering, product management.

Others say that designers are only good at whispering sweet nothings at Figma frames & complaining about not having a “seat at the table”.

The truth is at the intersection of the 80/20 parts of 2 opposing views.

But it truly doesn’t matter what caliber a designer you are if you’re Indie Hacking, because you won’t be able to escape the need to design things — from front-end experiences, to service, copy, research activities & more.

The boon to the Indie Hacker is that process almost doesn’t matter since you’re doing it all yourself. It can help, but it doesn’t matter after all.

Depending on the background & process-orientation, an Indie Hacker’s Design role is free to do whatever. No one is here to g-check your A game, call out your research biases, lack of accessibility considerations or lack of prototyping skills.

Rule #2 — Process is optional. Good design isn’t.

It’s not always crystal clear what value good design has until you compare an iPod to a Microsoft Zune.

In the early days of the journey, it’s useful to link good design to Marketing & Advertising.

Speaking of which…

The Indie Hacker is a Marketer

There are many memes in the Indie Hacker community about marketing.

Indie Hackers don’t like marketing.

It’s synonymous with sales to them. It’s extroverted & often feels not scalable. Or it can be expensive.

It also crosses paths with research (market, product, user) — and that means talking to people. And if an Indie Hacker wanted to talk to people… he’d Tweet.

But marketers in the corporate environment sadly also seldom talk to users. Depending on the caliber of a marketer, they might not even be aware of this need, or have the channels for those conversations.

So there’s a particular method of marketing that has made a few Indie Hackers successful. Writing & “Building in public” has become the almost inevitable go-to for this breed.

“Marketing is the act of telling stories about the things we make — stories that sell and stories that spread.” — Seth Godin

It makes sense.

When you’re all by yourself, you have to conserve energy. You can’t let it fan out in different directions that don’t loop back around and feed into your other activities.

Your audience is people who aspire to be like you, or are like you already. So by showing your work, you’re also selling to them — selling on the lifestyle first, and then “selling the pickaxes during the goldrush”.

If you find a way to do the things you hate in a way that’s nearly effortless, then you won’t hate them as much.

Rule #3 — Conserve energy for the important by making it effortless. Rule #4 — Marketing is non-negotiable.

The Indie Hacker is an Engineer

Last but not least: Indie Hackers build.

There is no other option.

You don’t have a team, you don’t even have co-founders.

Building is non-negotiable.

You can be bad at design, product & marketing — but if you can’t build, you’ve got nothing.

And this is usually the least problematic thing. You don’t go into making something without being de-facto a maker.

You ran away from a slow enterprise because things there move at a snail’s pace. Nothing gets shipped. They rest on their bags of gold, secretly envious of younger startups.

But the problem is that you do build. You build too much.

And that puts us back to the top of this article.

Pushing into a problem space is not that difficult.

“ALMOST ANYTHING IS EASIER TO GET INTO THAN OUT OF.” — Agnes Allen’s Law

But keeping a strong connection with the problem space is one of the most difficult things to do after the fact.

Once we’re down in the submarine trawling the dark depths, going deeper & deeper, dodging mishaps & misfortunes, you forget what waters you were in.

Then you’re in trouble.

Rule #5 — Everything is important, but the most important thing is that everything is important.

The life of the Indie Hacker appeals to me.

I made & launched prodmgmt.world in 2020 — but I yearn for more.

Do you agree with these rules? Would you add more?

If you’re like me, say hi on Twitter!