Before you go, check out these stories!

Hackernoon logoThink of Your Startup as an Ecosystem by@Dane

Think of Your Startup as an Ecosystem

Author profile picture

@DaneDane Lyons

CPO at Hacker Noon

👆Photo by Markus Spiske

Your product, team, users, sponsors, stakeholders, codebase, integrations, partners, social profiles, followers, and haters are all part of a crazy ecosystem more commonly thought of as a startup. Basically any person or thing with any connection to what you do is part of the ecosystem. Even that local coffee shop your dev team inhabits in the afternoon is part of the biological system.

Ok, so why does this matter?

I believe this shift in thinking can give us a greater appreciation for the bigger picture rather than being hyper focused on our individual roles and responsibilities. In particular, this is important when thinking about how we should invest our time and energy.

The team focus should revolve around the idea of building a healthy ecosystem that is sustainable and self perpetuating.

That might sound a little abstract so think about it more concretely. What are the "interventions" required by your team in order to keep your startup running? You likely have...

  • A marketing team responsible to bring new users to your product.
  • A sales team responsible for converting tire kickers to paid users.
  • A CS team responsible for helping struggling users get value from your product.
  • A management team responsible for coordinating dev efforts.

How reliant is your startup on these interventions? If revenue is directly proportional to how much you invest in interventions, then you lack sustainability.

It's unreasonable to imagine your startup can sustain itself and grow without investing energy pushing it forward, especially early on. But, the healthier your ecosystem is, the less energy you'll have to invest on maintenance and growth.

Investing in sustainability

The easiest way to start building a healthier ecosystem is to treat the cause, not the symptom when you run into a problem.

Imagine new users are having trouble figuring out your product. It's tempting to hire a bigger CS team to help onboard new users. A prime example of treating the symptom.

Treating symptoms mean you've got to create processes that require energy to respond to reoccurring triggers. No matter how efficient you make those processes, they'll still require constant maintenance energy.

It's ok to create temporary processes to treat symptoms while you work on solutions to the root causes. But these processes are band-aids, not cures.

In the case of users not figuring out your product, it's complicated but you've got to roll up your sleeves and keep iterating on the first time experience. Maybe your CS team will want to spend time with every new user but the goal could be to reduce the amount of effort down from an average of say 2-3 hours down to 5-10 minutes.

A good CS team is invaluable. But the purpose should not be to cover up product flaws. The CS team should essentially be the part of the product team that helps users solve problems and advocates for their needs.

Other examples of treating the root cause

1. In marketing, it's often tempting to invest heavily in ads designed to drive users to a landing page with the intention to immediately convert. If you stop pumping money into that machine, the whole thing immediately grinds to a halt. Marketing should be thinking about how things like brand equity and content can increase sustainability.

2. I often find a lack of communication between people building and people selling a product. Sales often tries to deal with gaps in functionality by figuring out clever hacks to solve common problems prospective users face. These hacks often involve gluing together 4-5 services and promising/hoping everything works. With more discussion between the teams, it's easier to understand and address user needs.

3. If your development team is always in "fire fighter mode" then it's pretty likely that the focus is on treating symptoms, not the cause. If that is the case, I highly recommend finding a way to time-box how much effort is spent hacking temp fixes to bugs and quirks. This will open up more time to build a better underlying system.


Not too complicated. Just think about how to invest in sustainability so you don't wind up with a fire that goes out the minute you stop pouring gasoline.


Become a Hackolyte

Level up your reading game by joining Hacker Noon now!