Ever had the experience of making what seems like a solid plan, getting into the work, and then quickly finding out reality doesn’t fit the plan? Odds are, something emerged that the plan didn’t take into account.
Customers behaved differently than predicted. That integration didn’t go as smoothly as the docs suggested it would. Implementing the new technology was harder than expected.
That’s complexity.
It’s easy to think, “We should have planned better.” But some things just don’t emerge until you get into the real work. Customers discover their preferences when they see a solution. Actually integrating two systems reveals edge cases no one had previously experienced (so, of course, they didn’t make it into the docs).
Some common sources of complexity in product development:
- Newness — Solving new problems, using new technologies, working in a new domain, adding new team members…all those new things lead to “unknown unknowns,” things we don’t discover or even know to think about until work gets underway.
- Humans — Anytime our success hinges on the future preferences and behaviors of humans, there’s going to be complexity. It’s just hard to predict what people will want and what they’ll do. If you’ve ever heard, “Now that I see it, I don’t actually want this, I want this other thing,” you’ve experienced this kind of complexity.
- Dependencies — When your work depends on systems, teams, or individuals outside your control, unpredictable things are bound to happen. Work isn’t ready on time. Other things take priority. Systems don’t behave the ways the documentation claimed.
- External Factors — Sometimes our products are vulnerable to unpredictability from markets, competitors, weather, regulation, or other external factors. We can’t control it, and it’s often hard to plan around.
Since most products worth building are something new built by humans for other humans, usually beyond the scale of one team, complexity sits right at the center of product development. The very reason why we’re building whatever we’re building is likely correlated to what’s most complex about it.
The classic mistake is starting with parts of the work that feel known and things that seem like essential but familiar foundations, putting off that complex thing. In the process, we defer value, we slow down learning, and we leave risk unaddressed.
Instead, tackle the most complex parts of an initiative first. Our CAPED approach (Complexity-Aware Planning, Estimation, and Delivery) is a systematic way to do just that.
Learn how CAPED brings complexity forward for early value, learning, and risk-mitigation while increasing predictability.
And if you have an initiative where the complex part keeps getting scheduled last, schedule a call. We’ll help you find where to start. Our initial calls often feel more like a free coaching session than a sales call.
Last updated