4 ms·

Looking back on SaaS product strategy

135 points by ghiculescu 3y ago

Linusvq 3y ago
This is a great read — appreciate the valley of “phase 2: too many things to prioritize” which is where I see most product teams get stuck - trying to over-index on being data-driven, or on MRR targets…
- tmpX7dMeXU 3y ago
  Startup culture ‘assembly line’ product development IMO.
- l5870uoo9y 3y ago
  The indie hacker approach to this is constantly develop, deploy and monitor. If the feature is used, improve it. If the feature is unsuccessfully used, improve it. If the feature isn't used, kill it. This is heavily data-driven and requires intuition for users' desires (what they want, how they want it) and your product. The latter takes years to learn.
  - arthurofbabylon 3y ago
    Indie hacker? Isn’t that just the approach of a good development team, solo or multi-person, in general?
    - l5870uoo9y 3y ago
      When working for companies the development process is longer and requires input from multiple stakeholders outside of the development team, e.g. product manager, project manager, copy writes. There is a substantial analysis before starting the development. As an independent hacker (indie hacker) you don't have those resources but instead increased agility and speed.
throwaway295729 3y ago
It’s not clear how the product team decides work to be done. The article jumps from data driven decisions not working to OKR’s that would apply once a product direction is set. Would be great to get some clarification
- ghiculescu 3y ago
  The specific decision point of “what code are we going to write next week” happens in a betting table: https://basecamp.com/shapeup/2.2-chapter-08 https://basecamp.com/shapeup/2.2-chapter-08
  - fatherzine 3y ago
    That chapter is a very refreshing read. Thanks for sharing!
- dsugarman 3y ago
  It's actually the reverse. The product direction is dictated by the goal (OKR). Our objective is to increase engagement from management which we know we are accomplishing by hitting the key result of admin users increasing average usage from y to x. From there a product team can generate ideas or prioritize ideas that fit the mold.
deleted 3y ago
[deleted]
bgoldste 3y ago
This is terrific. I loved the presentation of trying different approaches successively, and I think you nail the nuance of several early product stages that often get rolled together.
ozim 3y ago
As a developer I dislike "build all things even if they don't neatly fit in the system". I would like product people to come up with features that fit in and are thought out. It makes my work harder :) But at the same time I agree if we don't build it, we won't have customers and unfortunately keeping/geetting new customers is not exact science. In the end important part is to get rid of stuff that was build for big fish customer once they stop being customer because it keeps living in code base and after years no one remembers why that stuff is still there.
- ghiculescu 3y ago
  It’s definitely not an exact science! As a developer I feel the same, and as we matured it did slowly get easier to be more precise about what’s worth building.
- dude187 3y ago
  > But at the same time I agree if we don't build it, we won't have customers and unfortunately keeping/geetting new customers is not exact science. Read that as "unfortunately keep getting new customers" and all I could think of is clerks. "This job would be great if it wasn't for the customers"
quickthrower2 3y ago
> If you don’t already know about something that people want that you can explain in 2 sentences, then you shouldn’t be starting a business. Is this just gatekeeping?
- ghiculescu 3y ago
  No. Feel free to ignore it.
- deleted 3y ago
  [deleted]
grvdrm 3y ago
> Succumbing to pressure from big customers I'd love to hear how folks here handle this. What systems have you used to decide that either did or did not work? Where I am, we built things into our product for one of our three largest enterprise customers that no one else uses. And some of that work isn't aligned with the core product and strategy. Yet, the contract with that customer is among our largest and also covers that customer's other usage that IS aligned with our core product. I joined the company in the year after that contract closed. I look back at the decision (that I didn't make) and think that it completely distracted the company and product (and still does, just less). But in that moment, would I have said no that particular non-aligned use-case, and potentially walked away from the $? We're talking about a $1M+ annual deal. I don't know!
- bob1029 3y ago
  > the contract with that customer is among our largest At the end of the day you are presumably doing all of this to turn a profit. Not to uphold some arbitrary ideology regarding what a perfect product and perfect customer should look like. We used to look at "custom" code like some kind of awful thing (aka avoid on principle at any cost to us). At the financial scale we were operating at, it totally didn't make sense. However, as we started to gain traction and bigger customers started looking, the notion of maintaining a code pile per client started to make more sense. We even have some prospects with their own development staff who would be interested in assuming full ownership of product and source once we bootstrap it for them. My line in the sand is a million dollars annually, with a term no shorter than 3 years. If the customer can afford to pay more than this, then I think custom could be in the cards. Otherwise, I would push them into our standardized product offering. We've got a few prospects in this bucket today, but most are under the standardized offering. If you squint hard enough, much of SaaS is really just a big consulting package. The software is a shiny distraction to keep everyone participating. We only want to use just the right amount of software. No more, no less. The business can be much easier to change than the code in many cases. Sometimes back office processes completely evaporate when you get 2 employees together who have never met before.
  - xyzzy_plugh 3y ago

135 points by ghiculescu 3y ago

This is a great read — appreciate the valley of “phase 2: too many things to prioritize” which is where I see most product teams get stuck - trying to over-index on being data-driven, or on MRR targets…

tmpX7dMeXU 3y ago
Startup culture ‘assembly line’ product development IMO.
l5870uoo9y 3y ago
The indie hacker approach to this is constantly develop, deploy and monitor. If the feature is used, improve it. If the feature is unsuccessfully used, improve it. If the feature isn't used, kill it. This is heavily data-driven and requires intuition for users' desires (what they want, how they want it) and your product. The latter takes years to learn.
- arthurofbabylon 3y ago
  Indie hacker? Isn’t that just the approach of a good development team, solo or multi-person, in general?
  - l5870uoo9y 3y ago
    When working for companies the development process is longer and requires input from multiple stakeholders outside of the development team, e.g. product manager, project manager, copy writes. There is a substantial analysis before starting the development. As an independent hacker (indie hacker) you don't have those resources but instead increased agility and speed.

throwaway295729 3y ago

It’s not clear how the product team decides work to be done. The article jumps from data driven decisions not working to OKR’s that would apply once a product direction is set. Would be great to get some clarification

ghiculescu 3y ago
The specific decision point of “what code are we going to write next week” happens in a betting table: https://basecamp.com/shapeup/2.2-chapter-08 https://basecamp.com/shapeup/2.2-chapter-08
- fatherzine 3y ago
  That chapter is a very refreshing read. Thanks for sharing!
dsugarman 3y ago
It's actually the reverse. The product direction is dictated by the goal (OKR). Our objective is to increase engagement from management which we know we are accomplishing by hitting the key result of admin users increasing average usage from y to x. From there a product team can generate ideas or prioritize ideas that fit the mold.

deleted 3y ago

[deleted]

bgoldste 3y ago

This is terrific. I loved the presentation of trying different approaches successively, and I think you nail the nuance of several early product stages that often get rolled together.

ozim 3y ago

As a developer I dislike "build all things even if they don't neatly fit in the system". I would like product people to come up with features that fit in and are thought out. It makes my work harder :) But at the same time I agree if we don't build it, we won't have customers and unfortunately keeping/geetting new customers is not exact science. In the end important part is to get rid of stuff that was build for big fish customer once they stop being customer because it keeps living in code base and after years no one remembers why that stuff is still there.

ghiculescu 3y ago
It’s definitely not an exact science! As a developer I feel the same, and as we matured it did slowly get easier to be more precise about what’s worth building.
dude187 3y ago
> But at the same time I agree if we don't build it, we won't have customers and unfortunately keeping/geetting new customers is not exact science. Read that as "unfortunately keep getting new customers" and all I could think of is clerks. "This job would be great if it wasn't for the customers"

quickthrower2 3y ago

> If you don’t already know about something that people want that you can explain in 2 sentences, then you shouldn’t be starting a business. Is this just gatekeeping?

ghiculescu 3y ago
No. Feel free to ignore it.
deleted 3y ago
[deleted]

grvdrm 3y ago

> Succumbing to pressure from big customers I'd love to hear how folks here handle this. What systems have you used to decide that either did or did not work? Where I am, we built things into our product for one of our three largest enterprise customers that no one else uses. And some of that work isn't aligned with the core product and strategy. Yet, the contract with that customer is among our largest and also covers that customer's other usage that IS aligned with our core product. I joined the company in the year after that contract closed. I look back at the decision (that I didn't make) and think that it completely distracted the company and product (and still does, just less). But in that moment, would I have said no that particular non-aligned use-case, and potentially walked away from the $? We're talking about a $1M+ annual deal. I don't know!

bob1029 3y ago
> the contract with that customer is among our largest At the end of the day you are presumably doing all of this to turn a profit. Not to uphold some arbitrary ideology regarding what a perfect product and perfect customer should look like. We used to look at "custom" code like some kind of awful thing (aka avoid on principle at any cost to us). At the financial scale we were operating at, it totally didn't make sense. However, as we started to gain traction and bigger customers started looking, the notion of maintaining a code pile per client started to make more sense. We even have some prospects with their own development staff who would be interested in assuming full ownership of product and source once we bootstrap it for them. My line in the sand is a million dollars annually, with a term no shorter than 3 years. If the customer can afford to pay more than this, then I think custom could be in the cards. Otherwise, I would push them into our standardized product offering. We've got a few prospects in this bucket today, but most are under the standardized offering. If you squint hard enough, much of SaaS is really just a big consulting package. The software is a shiny distraction to keep everyone participating. We only want to use just the right amount of software. No more, no less. The business can be much easier to change than the code in many cases. Sometimes back office processes completely evaporate when you get 2 employees together who have never met before.
- xyzzy_plugh 3y ago