Maintaining Product/Market Fit Over Time

I know, this is kinda ridiculous. Just for argument’s sake though, let’s pretend that you’ve got your act down — you built your product it’s actually selling, and you’ve got $$$. You’ve achieved that elusive Product/Market Fit, where the thing you’re building is the thing that people want, and are willing to pay for.
Product/Market Fit EvolvesThe issue with having achieved Product/Market Fit is that things change. People might be willing to pay for your widget today, but will that be true tomorrow? After all,
  • • Competition might bring other players into the market, who could sell the same thing for less. After all, they’ve already seen what works, don’t need to recoup R&D like you did, etc.
  • • Customer needs evolve, heck, you might be the one that’s causing them to ask for more! Are you prepared to satisfy those needs?
There are other reasons why what works today might not work tomorrow (market gets tapped out, regulatory changes, etc.).
The point here being that you need to evolve to meet tomorrow’s needs. To be precise, Product/Market Fit is a moving target. When you get down to it, it’s also part of the reason that Agile is so long on Customer Collaboration, and Responding to Change — by keeping your customer’s in the feedback loop, and constantly updating your priors/requirements, you’re never in a state of “Done”, your Product is constantly evolving with the Market.
In short, what you need to do to succeed is actually
  1. 1. Build Product
  2. 2. Sell Product
  3. 3. Update, and Iterate
This is your Virtuous Cycle, and is necessary (but not sufficient!) for Product/Market Fit.
Process Matters
Let’s look inwards though, at the actual functioning of your company. The thing is, your company is constantly changing
  • • Turnover — employees leave, new ones show up, and all for a variety of reasons, with
  • • Culture/Morale— the DeathMarches you were so fond of during startup are no longer tenable
  • • Technology — You’ve hit an inflection point, and need major changes to continue scaling
The result is that about the only commonality between the company you have today, and the one that you had a few years ago, is the name, not unlike Theseus’ ship(•)
The problem is that you can’t rely on people to make sure that things will continue to work. People get hit by buses, #RageQuit, and so forth — heck, that’s why Turnover is the first point above!
Even if turnover is low, Oral Tradition isn’t all that much better. It may have been great for Homer, but unlike him you’re job doesn’t consist of repeating the Illiad and Odyssey over and over and over again 😆
And that’s why Process matters so much, and Documented Process at that. The more you bake the Virtuous Cycle above into your systems and processes, the more likely it is that it gets maintained as the company evolves. Equally importantly, these need to be Defaults, i.e., deviating from these systems and processes should take effort — with the “beneficial” processes being the default (a-la “Nudge”).
By the way, don’t overlook the “Documented” part of “Documented Process” — after all, you don’t want to regress back to Oral Tradition! That said, the documentation doesn’t have to be ISO 9000 level insanity, it can include things like your Continuous Delivery environment, your Requirements Management workflow, and so forth. Just make sure that you actually keep track of the reasons why you made whatever choices you made…
(•) To paraphrase Plutarch ”If the ship on which Theseus sailed has been so heavily repaired and nearly every part replaced, is it still the same ship — and, if not, at what point did it stop being the same ship?

Comments

Popular posts from this blog

Cannonball Tree!

Erlang, Binaries, and Garbage Collection (Sigh)

Visualizing Prime Numbers