The Evolution Dimension
Magic happens on mountains.
There is a long, although not consistently documented history of this fact.
A notable early example is from 1446 BC (disclaimer: this is a surprisingly-specific AI-generated estimate): Moses spent some quality time up mountain Sinai, and came down with the 10 commandments.
Since then, a slew more instances of mountain magic occurred, but for brevity we’ll fast-forward about three-and-a-half millennia.
This brings us to 22 years ago when the mountain struck once more: some smart people met at a mountain resort in Utah. They did some skiing. They talked. They ate. Then, they came down the mountain with a manifesto on how to properly build software, and put it on an incredibly ugly website. Agile was born. You’re welcome, world.
Mountains are great. They’re the provider of ultimate answers. They drive human kind forward.
You see, while the Agile folks were doing their skiing up on that hill, I was living in one of the flattest countries on earth, learning about the Rational Unified Process (RUP) as the silver bullet of software development processes. I spent dozens, possibly hundreds of hours in lectures and doing exercises on how to write requirement documents, functional designs, implementation and test plans. Software Engineering meant: writing documents. Tons and tons of documents. And drawing of course. UML! Oh my, a well-crafted activity or class diagram still gives me goose bumps.
But then those bastards went up some hill, invented Agile and — poof. Life would never be the same again.
These days I only use my UML drawing skills with my kids, and they show shocking little appreciation. Kids these days.
But you can’t stop progress. Especially if it’s mountain sourced.
Software development process-wise, we got RUP in the late ‘90s. Then Agile in the early ‘00s. Then Validated Learning in the early ‘10s. And then Big Tech came along and figured out how to scale validated learning to insane levels later that decade. I have not yet been able to prove my mountain theory for each of these, but I bet you — there’s a mountain involved there somewhere.
And there we have it, the current state of the art: experiment all the things. Formulate your hypotheses. A/B test everything. Build fake landing pages until you make it.
You’re not doing this yet? Oh my, your software development approach is so ten minutes ago, keep up!
RUP? Hah!
Scrum? Meh.
Kanban? Mkay.
Validate Learning? Yeah!
Ridiculously parallel validated learning? Booyah!
I started a new job two weeks ago. I joined Jimdo to lead product engineering. In this second week, I was sent on my first mission. The mission: to figure out a new home for a particular feature.
Here’s how I would generally approach deciding where ownership of a feature should land. I’d think about:
- What is the scope, and what teams is this a natural fit for, topic-wise?
- Does this team have the required skillset?
- Does this team have the required capacity to take this on as well?
Easy enough.
But then, I was given a “hint.”
“Probably it should go to one of the funnel teams,” I was told. “It seems like a funnel—y thing.”
At Jimdo, the “funnel teams” are growth-focused teams that are responsible for converting incoming potential customers, guiding them through sign-up, and eventually upgrading them to paid customers.
Funnel-y thing, you say. What is that supposed to mean?
“Well, you know, it’s fast moving. Lots of experiments, yada yada.”
I was confused, that just sounds like The Way, no? Shouldn’t all teams operate through experiments? I mean, validate and learn all the things, right?
This resulted in some reflection on my part. And whenever I’m forced to think (this happens rarely, so don’t be alarmed) — proverbial shit is about to hit the proverbial fan.
I started to ask myself all kinds of existential questions:
What if there is a 4th dimension to take into account beside scope, skill and capacity?
What if my assumptions about “best practices” and “ideal mindsets” were misguided?
What if those Agile dudes didn’t come up with the silver bullet of software development processes? And if that were true...
What if mountains don’t lead to magic?
Hah, no, let’s not completely shatter the foundations of my belief system. Mountains = magic.
As I said: don’t make me think. Everything you taught to believe may be shattered.
I suddenly remembered that some years ago, I got acquainted with Simon Wardley, the inventor of Wardley Maps. I won’t get into strategy mapping much, but one observation he makes is that trying to decide on a single development process to rule them all is rather silly. He’s British, so we’re not allowed to giggle when he uses words like silly. Also, when Simon says, for hard to nail down reasons we feel the need to listen.
Why is there no size fits all? Simon says there are different stages in product evolution, and they benefit not just from different development processes, but different personality types and different mindsets too.
Oh no, that sounds like something that is going to complicate things...
Many of us enjoy some leisurely people categorization, and Simon is no different. He identified three types:
Pioneers are the type of people that love running ahead of the curve. They love exploring new ideas and using new technology. They’re perfectly fine with not knowing what to expect and just throwing things at the wall. Their development approach? YOLO Driven Development. Will this work? Who knows, let’s try! YOLO! They are less interested in long-term thinking. They love exploration: see what works and what doesn’t.
Settlers are the type of people that lover to turn crazy ideas into real products. They can take something that a Pioneer has discovered, and productize it. Something you can sell, something that customers will gladly pay for and use.
Town planners take what is known to work and scale it. They love to engineer things properly; to make things super robust and optimized. The things they build form the foundation that settlers and pioneers build and rely on.
Note there’s no judgment here. One isn’t better than the other. All of these personality types can be valuable when put in the right context.
Cool story, but how is this relevant to a product company?
Typically, there are areas of the product that you’re still exploring; where we’re still figuring things out. For instance, you’re still figuring out what the ultimate customer journey looks like. You’re still figuring out what features customers do or do not need. What needs to be done is try things, and try them fast. Then ditch what doesn’t work, and move on with your life. This is not a place where town planners would be very happy, nor settlers. This is pioneer territory. Settlers and town planners would get very nervous and frustrated in this type of environment. This has time horizon implications also. This is not the place where you can realistically do multi-year roadmapping exercises, you have to be able to pivot month by month, at times week by week. Since your planning is always short-term, your process needs to follow suit. Validated learning, Kanban, running experiments is The Way in pioneer territory. The shortest cycles that are practical.
Then there are parts of the product you understand much better. Customers are using these features and rely on them. They have to work and continuously be improved. Here you can look a little further ahead and probably make a reasonable plan for a year. The chances that we have to throw our plans out the window next week is lower, so we can make our cycle times longer and focus on predictability and quality. This is where processes like Scrum make more sense. This is the place for settlers. Pioneers would get bored, and town planners would distract.
Finally, there are parts of the product that are more standard. Standard, but not available off the shelf. To run your product, you need infrastructure. Cloud infrastructure, billing, tooling, design systems. The priority here is stability, performance and cost. When you talk to people in this area, they will mention plans they’re looking at for the second half of the year or even next year. For a pioneer or settler this type of talk doesn’t compute. Who thinks that far ahead? Town planners do. This is a space where Gantt charts make sense. This is where you can and should spend a lot of time on planning and writing things down in documents. I wouldn’t invoke RUP and UML just yet, but you could borrow some of their practices, it wouldn’t be all that crazy.
A brief legal disclaimer: All these descriptions are caricatures and should not be taken too literally. What would “taking it too literally” look like? Self-proclaimed Pioneering teams pushing straight to production on a Friday afternoon without testing, while group-chanting “YOLO, because Zef said sooo!” While I appreciate the enthusiasm, never deploy on a Friday afternoon, that’s just not cool.
So, why am I bringing all of this up?
I mentioned three dimensions to figure out where a particular product feature may be a fit: scope, skillset and capacity. As I realized this week, there is a fourth one: stage of evolution. Is this a feature that is completely established and fully understood? Send it to a town planner team. Is it one that drives the business, that needs to be productized and whipped into proper quality shape? Off to the settlers you go. Are things still up in the air, and we don’t know what this feature will look like in even a few months or if we will even have it? Pioneering territory!
I’m flying to Austria next week, I hear they have mountains there.
Over there, me and some smart people (my new team) will meet in person for an offsite. We’ll talk. We’ll eat. I hope we won’t ski. Then, at the end of the week we’ll come down the mountain. I can only assume magic will have happened.
Agile has had a good run. It’s time for the next big thing.