[HN Gopher] Looking back on SaaS product strategy
___________________________________________________________________
Looking back on SaaS product strategy
Author : ghiculescu
Score : 125 points
Date : 2023-10-06 23:12 UTC (23 hours ago)
(HTM) web link (ghiculescu.substack.com)
(TXT) w3m dump (ghiculescu.substack.com)
| Linusvq wrote:
| 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 wrote:
| Startup culture 'assembly line' product development IMO.
| l5870uoo9y wrote:
| 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 wrote:
| Indie hacker? Isn't that just the approach of a good
| development team, solo or multi-person, in general?
| quickthrower2 wrote:
| > 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 wrote:
| No. Feel free to ignore it.
| [deleted]
| [deleted]
| ozim wrote:
| 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 wrote:
| 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.
| bgoldste wrote:
| 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.
| grvdrm wrote:
| > 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 wrote:
| > 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.
| grvdrm wrote:
| >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.
|
| What a great paragraph and overall reply. Thank you. I really
| like the bit about shiny software in particular. Also, the
| quick point otherwise about arbitrary ideology. At the end of
| the day, a lot of us are not building products driven by some
| serious human/moral/emotional mission. Instead, they're
| fairly ordinary enterprise (or other) SaaS products. So - ok
| to take the money too.
| xyzzy_plugh wrote:
| This is correct.
|
| Another way to frame it is to be upfront about development
| costs for custom features and bake it into the contract. A
| few ways I've managed to do this in the past:
|
| If the feature seems like it will benefit all customers, but
| is not a priority, push back on timeline. Otherwise, validate
| with other customers and try to get multiple customers
| interested and/or on the hook financially to fund the work.
|
| If the feature seems like it may be will benefit some other
| customers but is not a high priority, then you offer the
| customer the ability to partially fund the development and
| work closely as a partner to accelerate building to spec.
|
| If the feature seems like it might never be applicable for
| other customers, my preferred approach is to say no, with an
| alternative proposal of building something jointly (i.e. we
| will consult for you to help you build this on our platform)
| while facilitating their ability to build the thing through
| whatever means (API improvements, examples, etc.). This
| always comes at a substantial markup over SaaS sticker price.
|
| Basically, unless you were going to do it anyways, get
| funding for it, and even if you were going to do it, try and
| get funding for it anyways. Mature organizations are used to
| this game and won't be shy to discuss options.
|
| The only caveat is when you openly advertise something in
| development or on a feature roadmap, it becomes much harder
| to lobby a customer to fund it. I usually advise founders to
| stick to table stakes features for the roadmap, like SSO. A
| savvy mature customer will have a purchasing team that
| actually reads your website to find opportunities to out
| negotiate you.
| throwaway295729 wrote:
| 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
| dsugarman wrote:
| 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.
| ghiculescu wrote:
| 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
| fatherzine wrote:
| That chapter is a very refreshing read. Thanks for sharing!
___________________________________________________________________
(page generated 2023-10-07 23:02 UTC)