It’s taken much longer than I had hoped (because we often don’t share and learn from the negative examples in this industry), but I feel like the end of SAFe is coming:

This from @sbhigham is pretty accurate. Double the timeframes if your org has more than ~50 people in Digital/Tech. Double it again if you have over 250. This is why I advise orgs to not forecast any more than 1 Quarter into the future. Beyond that, your confidence interval is probably somewhere between 0-25%. I…

Love this Twitter/X post from Pawel Huryn. It’s an excellent summary of a “via negativa” exploration of the role of Product Management as part of the whole Product Development ecosystem: Thanks for sharing, Pawel.

Loads of organisations are heavily reliant on using platforms provided by others. But how to work in partnership with those Platform Providers can be difficult. Having been on both sides of this in my career, here’s a few pointers for the customers of platform providers to look out for. Caveat: this is oriented mostly at…

A bit of a rant from Threads: Post by @blackswanfarming View on Threads “The Business” – this is a phrase that should be used sparingly in Product Development, if at all. How does it show up? “What does the business want?” is one example.Have you ever heard, “The business wants X” or “The business need Y”?“The…

This may seem a bit off topic, but losing your life savings due to a phishing attack that drains your accounts is a Black Swan event for many folks. Even though phishing attacks are common enough to regularly make the newspaper, the status quo for financial services when emailing customers is still quite bad. When…

Not much more to say on this. It’s not that hard to grok. We manage to do it with “sheep”, without too much confusion (past the age of about 4 or 5). We should probably put the same effort into our National Bird that also serves as a reference to the people of Aotearoa New…

Seen this many times. Feels good, but the feeling doesn’t last, and it doesn’t solve the fundamental problem. In fact, it prolongs the problem, which is a bit sad. Firstly, let’s understand the motivation. The problem The team is overloaded. They’ve been working on a few really important things, and (surprise, surprise) those have turned…

It’s the 2020s (or as my kids say, “The 20’s”) and we’ve still got organisations using outdated methods for managing software endeavours. A big part of the reason that’s the case is that folks haven’t quite realised that software isn’t like building or renovating a house or building a bridge. It’s different in a whole…

Fairy tales are tempting. Especially so when it comes to big complex missions that have a lot of money, time and risk associated. Decisions need to be made at the point where we don’t know a whole lot, but that’s uncomfortable. And there’s lots of knock on effects and dependencies on reaching the goal –…

Just realising that I’ve not posted anywhere a graphic that I’ve been using for over 10 years now. These are the three different perspectives that are usually in tension within a Product Squad setup. Yes they overlap, so it’s not a tidy roles and responsibilities, and don’t even attempt to do a RACI with it.…

This post is a follow on from an overview of the Product Development Heartbeat. The Quarterly Look Ahead (QLA) is the part of that overall rhythm that pulls together teams, stakeholders and the wider org and helps with alignment to strategic goals and outcomes or objectives. So, how to approach this Quarterly Look Ahead? Hurry…

Lots of organisations as they grow start to struggle with how to stay aligned while maintaining the autonomy of when they were smaller. What works for one or two squads starts to fall apart at four or five and is generally untenable above Dunbar’s number (~120 people). Here’s a rough way to organise and operate…

This thread is a classic Black Swan story. (Fair warning, the 1 of 2 is a classic underestimation.) Still worth your time reading. And just to copy it here in case Twitter/X falls over or it gets deleted: Here is the story of Rimac: About 15 years ago, a Croatian dude appeared on a DIY…

In my travels in Product Development over the last decade or so, I’ve seen up close the value destroyed and delays incurred as a result of falling into three common traps. They’re all seemingly harmless or perhaps even considered good, but there’s some serious downsides that only become obvious much later. If you’re looking to…

2023 has been tough for a lot of organisations. As inflation got away on central banks interest rates headed north and all of a sudden it was all a bit different. What we’ve seen is that some were a bit drunk on cheap debt. Some organisations seem to have overhired. Others found that search for…

Steve Jobs, “A Bicycle for the Mind” – on the invention of the personal computer: I remember reading an article when I was about 12 years old – i think it might have been Scientific American – where they measured the efficiency of locomotion for all these species on planet Earth, how much energy did…

Product Development is a lot more like farming than it is like a manufacturing line or an engine. Manufacturing is usually incremental – lots of different parts with carefully controlled size and shape all need to be put together. Product Development on the other has is iterative. We repeat our process many times building on the…

Product Development involves tough choices and trade-offs. Here’s a typical one: what would you choose to optimise for? 1. Predictability (“on time, on budget”) 2. Throughput (Storypoints or maybe # of stories) 3. Speed (cycletime from idea to live) Of these three, a lot of organisations have a strong bias that optimises for predictability. Not…

Some guiding principles that have emerged for me over the years of inheriting somewhat broken Product Development organisations – and the approach that has worked well for me. 1. Start where you are If you’re relatively new, or taking on a new area, first do no harm. Chesterton’s Fence applies. Without a good understanding of the local…

This is from a while ago, written as an attempt to provide an overview of how these three roles have changed and how a large and complex organisation might transition from a more traditional setup to a more modern “fighting fit” one. Posit: the Business Analyst role is fading The role of Business Analysts in…

Best to break this into a couple of key areas: a) major investments, and b) baseline risks, things you as an Exec team and/or Board of Director’s should probably be aware of. Major Investments tend to get a lot of focus up front, but often go sideways in similar ways and for similar reasons. Baseline…

Hard agree with Cyd Harrell: Launching is not success. Success is your product solving the problem it’s intended to solve, for the people you intended to help, without harming other people. If you can’t state what you’re solving, who it helps, & who could be hurt, you’re not ready to build let alone launch –…

Cost of Delay is a very different animal to many of the concepts that people try to shoe-horn it into. Sometimes those are useful analogies. Other times, it’s not helpful, and leads to confusion, missing the actual power of Cost of Delay. A Is Cost of Delay like a really high NPV discount rate? For…

Here’s a perfect illustration of how organisational culture works: Something underneath the surface (not explicit or visible to individual actors) quietly amplifies conformity and dampens outliers. This is of course, a paradox. It’s a “good” thing when it comes to mission, vision, and rejecting toxic behaviour. It’s a “bad” thing if it means conforming thinking,…

CBDC discussions seem to be heating up. Be interesting to see where each of these four work streams at the European Central Bank lead to: “First, we will test the compatibility between a digital euro and existing central bank settlement services (such as TIPS),” outlines Panetta. Second, we will explore the interconnection between decentralised technologies,…

Improving the product along obvious parameters of value as defined by your customers today tends to lead to overserving. At some point, it becomes more than they can absorb. Remember the “Advanced Photo System”? You have to be careful about Overserving. It’s tempting to offer all the bells and whistles that customers ask for or…

The second key lesson you might have already spotted in the example from Lesson 1: The JOB doesn’t change, The Product we hire does. Consider the previous JTBD, “sharing a moment with others”… Below is a (totally science fiction today) product from Magic Leap, an Augmented Reality startup working on overlaying 3D images on your…

As a Product team, it’s tempting to look at the product itself and focus almost entirely about how to make it “better” along parameters that we already measure, especially the ones that existing customers ask for. This is what Christensen calls “sustaining innovation”. What Jobs To Be Done suggests, however, is that we focus on…

Jobs to be Done is a way of thinking about products and services. Using JTBD as a way of thinking brings a different perspective that helps us: Avoid building things that no one wants. Understand at a deeper level what a product needs to do Reveal why and how people choose a product or service…

The late Clayton M. Christensen researched and wrote one of the most frequently referenced books on innovation: “The Innovator’s Dilemma – when new technologies cause great firms to fail“. In it, Christensen outlines how companies tend to do everything “right” but in doing so, fail to successfully adopt new technologies. The book’s thesis is the…

“Technical Debt” is NOT the result of poor programming – it is the cost of not refactoring as you learn more about a solution. Like all things popular, “Technical Debt” has become a widely misunderstood and abused term. In some cases, Tech Debt is everything done by those who have gone before, “OPC”: Other People’s Code. Other times,…

TL;DR: Poorly. Not recommended! If you want to delve into the details, read this. (The main problems are that it uses some made up relative terms and then combines them in a way that is illogical.) If you’ve already started using the made up relative terms that SAFe suggests, all is not lost. At least…

Years ago, I wrote about funding teams instead of projects. That covered a really common big-batch funding and approval problem: the feast and famine – and the learning curves that teams go through before they’re really effective. In it, I also suggested some alternatives to big-batch project funding, giving you smoother flow of value plus…

Ever been “held accountable” for something that you had no control or power over? I’ve previously spoken about how corrosive the words we use in organisations can be. Words matter. And some words tell you quite a lot about an organisation. One thing I’ve observed is the use of the phrase “hold to account” tends…

I rather rudely butted in on an interesting twitter exchange yesterday, which started off about assessments. John Cutler was sharing what he has learned from doing and iterating on them recently. Having done quite a few assessments over the last decade (and iterated and improved how we go about it) the observation I shared was…

Over the years, I’ve spent a lot of time with senior Executives of different organisations. Along the way, I’ve noticed a tendency for them to latch onto, and misuse, the concept of “Velocity”. Too often, I’ve heard someone say something along the lines of “We need to increase our Velocity.” Whilst the terminology here really…

Someone asked the above question, and whilst it seems facile, I couldn’t resist… Short answer: because there’s no profit in it. Slightly longer answer… This quote from Tim Cook (emphasis mine) may seem to contradict the shorter answer, but bear with me: “Stock price is a result, not an achievement by itself. For me, it’s…

Had an interesting conversation with John Cutler yesterday to discuss the idea of having a single prioritised Backlog for an organisation. The genesis for the chat came from a tweet that John posted, to which I responded: In the spirit of exploration and “strong opinions, weakly held, I’d love to debate this one with you.…

Abstract: Jobs to be Done (JTBD) is an interview technique and way of thinking for revealing deeper insights into why people choose a product or service. Using JTBD helps us to avoid building stuff that no-one wants. It is a way to better understand what a product or service really needs to do. Why this…