Home
Starting Up
Case Studies DB
Products
Ideas DB
Vibe Coding Tools
Subscribe to IH+
Starting Up
Case Studies
Ideas DB
Products DB
Join
15
Likes
15
Comments
Why developers should own the product and how it will make them happy
by
uxland
https://hackernoon.com/why-developers-should-own-the-product-and-how-it-will-make-them-happy
I think this is probably why a lot of Indie Hackers either branch out on their own or at least start building their own side-projects: leaders often down encourage developers to take ownership over the whole product - it's a "solve this" and move on to the next thing approach.
Yeah but at the end of the day, even an employer encourages you to "own" a project, you don't necessarily get the same sense of ownership as you would with your own product - the company you'd be working for would have still chosen what the product is. Owning the project/product might give you a sense of ownership in an economic sense, but it doesn't give you the meaning that building your own product would.
It depends, though. As the article explains, there are "Type X" and "Type I" people:
"Type X are people for whom extrinsic motivation is paramount: how much money they will earn and what rewards they will receive. People of Type I are primarily interested in internal motivation — satisfaction from work done. "
So, you can derive a sense of ownership from both the economic perspective or the intrinsic sense of meaning building the product gives you. I'm sure a lot of Indie Hackers build products they don't necessarily think will majorly improve people's lives or the planet...if there's demand, they build and the potential financial return is enough to drive them.
Totally agree. Probably the most important point is how it impacts productivity, which can impact motivation.
"A developer who feels like he owns the product does not wait for instructions but is proactive. They warn about risks in advance, correct mistakes, and come up with suggestions."
I think caring of ownership or not also sets a strong indicator for good and bad developers in collaboration. A good developer is proactive and always asks for the task ownership. They bother so much about the outcome of their work so you can very much trust their autonomy at work. In contrast, a bad one, as I have met many, cares much less their task ownership. As a result, the quality of their work can be shaky so you will always need to review and be wary of the impact. This unfortunately ends up a vicious circle in a collaboration relationship.
This is a myth. There are far more developers than products. Heck, look at all the megatech, most of their engineers don't own anything.
Some good information, especially for employees
Great post! Does website count as digital product? https://alightmotionproapk.net/
I think this is a fancy way of saying that they should also think about the business, not just their code.
other words, developers should think on WHY they are coding in the first place.
Is it because you want to save the business money?
Or because you want to improve a certain process people are doing manually?
A guy I knew once told me software exists for 3 reasons:
What is that SOMETHING you are trying to make faster/more predictable/easier? Knowing the answer will give you "ownership".
I was a frustrated developer because I always wanted to innovate and they never let me. However, since now I am a full-time indie hacker working on my own business, I realise how little I knew about business.
Developers do not have the knowledge and overview to lead a product.
They need to understand what the users want and what makes money. With that said, I think companies should teach entrepreneurship to the devs that are interested in assuming more product responsibility
I've used so many products that worked so poorly, I immediately wondered if whoever was selling the thing actually used it themselves. I feel like when developers own what they are working on, they are so much more likely to be deeply engaged, and to avoid creating something that ever feels so unintuitive or clunky to the user.
I remember hearing about a company — was it Basecamp? — that essentially shared their north star metric with all its employees and then gave them free rein to do whatever they thought would push the needle for the company.
Seems like it could be a bit of a shit show, but apparently it worked for them.
Yeah, I'm definitely guilty of focusing solely on killing Jira tasks. I don't know if it's just my personality type, or if it's that that's where the overt incentive is, or what. But I catch myself doing it all the time.
I have to remind myself to take step back and see the big picture. I actually find it's helpful to set a recurring task to zoom out once a week, review/update goals, and brainstorm on the product as a whole.
If you aren't solo like me, I'd let your team in on the strategies, the challenges, the goals. And make it clear that their job goes beyond their todo lists (and make sure your incentives to back that up).
The idea of having 'skin in the game' is what's always called out to me.
The IKEA EFFECT really nails it.
When we invest our time into something (and are recognized for it) we value it more and thusly, invest more time.
When I hire I will be sharing the pie because it makes the pie bigger.