Curious. Useful.

flowchart LR
    id1["Ambiguity"]
    id2["Stimulus"]
    id3["Uncertainty"]

    id4["Discovery"]

    id5["Options"]
    id6["Insight"]
    id7["Action"]

    id1 --> id4
    id2 --> id4
    id3 --> id4
    id4 --> id5
    id4 --> id6
    id4 --> id7

    click id1 "#ambiguity" "More on Ambiguity"
    click id2 "#stimulus" "More on Stimulus"
    click id3 "#uncertainty" "More on Uncertainty"
    click id4 "#discovery" "More on Discovery"
    click id5 "#options" "More on Options"
    click id6 "#insight" "More on Insight"
    click id7 "#action" "More on Action"

Something's Off

Have you ever joined a project that just felt off?

Everyone is really busy, and there are lots and lots of things to do. Lots of clever solutions to difficult problems are being worked on: big, complex, stuff. Requests for all sorts of changes flow into the project, and prioritisation is difficult. Stakeholder interactions, when they happen, are surprising, with everyone seemingly having a different view of what is critical. There's a lot of reporting going on, with some people spending what seems like their whole day producing updates and presentation decks.

Something is gnawing at you.

You assumed that because you were new, you just didn't "get it" yet. You're probably missing key information, or you don't yet understand the domain well enough, or maybe you're just not smart enough. But as the weeks go by you don't feel more at ease. If anything, you become increasingly troubled. Sure, the way things are being built seems decent and there are some really talented people on the ground. But why are we building what we are building? Do we really need all of this stuff? How did this ever get sign-off? Who is the actual customer and what really is the problem we're trying solve for them?

You begin to voice your concerns to your coworkers.

Some seem wholly unconcerned. Others are more circumspect. Yes, you may have a point in some areas, but you shouldn't be so worried. After all there is decent governance in place and people know what they're doing. You get a strong "stay in your lane" signal from the product director.

You're Not Alone

If you've felt like this, you're not alone. "It's not unusual" as someone once said.

The budget approval process for such a project is often a confidence game - placing a big bet on what seems like a good idea that has senior backing, usually coupled to numerous commitments about dates and revenues. Once commissioned, big projects are hard to steer (that's why they have so many steering committees) and near impossible to stop. Contracts, budgets, supplier relationships, commitments; all things that are much easier to get into than out of. The feedback loop with reality can be slow (or non-existent) as doing the work to hit the dates becomes the priority.

Didn't We Fix All This?

Changes to software development methodology (and to product management methodology, to a lesser extent) in the 2000s and 2010s sought to address these problems. Iteration, TDD, time-boxing, user stories, limiting WIP, the XP metaphor, products over projects, continuous integration and delivery etc. each came at the problem set from different directions. Do less, take small steps, be more explicit, agree on common language, automate. All good stuff, and at Energized Work we went long on them. We delivered. But despite all the effort, we still ended up taking on our fair share of crap projects - joyless initiatives that end customers were lukewarm about, at best. Why?

When I hung up my gloves on EW in 2018, I was deeply confused. Why, despite all the commitment, skill, knowledge and energy, working alongside some truly great people, did so many projects feel like such an uphill battle? Why did our methods seem to blunt when faced with having to unwind some major project assumption that turned out to be wrong, or feeling like we were having to force our solution onto unwilling staff, or having to build something to satisfy stakeholder promises rather than paying customers? Maybe we were just doing it all wrong (this is the internet after all - I'm sure someone will point this out) but I concluded the problem was deeper than that. Much deeper.

Wrong Place, Wrong Time

We always seemed to be in the wrong place, at the wrong time. Worse than that, we had the wrong skills, or at a minimum we didn't appreciate the importance of certain skills we needed to be effective. "We must get in early", people said. But how? And what would we do? Every early stage conversation was focused on time and cost - when can you deliver and for how much. The solution narrative had already been written and any serious challenge to that story would yield "that decision has already been made". Invariably, when asking about how they got there, numerous decks would be produced but little in the way of hard evidence. It was a hunch, wrapped in impressive looking graphics and authoritative sound bites. A Big 4 logo was icing on the cake.

Harold F. Dodge said "You can not inspect quality into a product.". He was talking about manufacturing physical products. This is also true of digital products and of their underlying ideas: if they are based on faulty assumptions, reality will win out in the end (note: even for "AI" initiatives). We can test-drive quality into the code all day long and use the latest and greatest technology, but if the underlying dynamics are off, we can't fix it at this level - wrong place, wrong time.

Risks and Decks

The Lean Startup described 3 major product risks: viability, feasibility, desirability; Marty Cagan at SVPG re-expressed these as the Four Big Risks, classifying them into value, usability, feasibility and business viability risk. I like this latter frame, having experienced numerous situations where business viability risk (does this actually work for the different aspects of our business - compliance, marketing, risk etc.) was one of the toughest hurdles to overcome. Whichever model or framework you prefer, a product idea really benefits from being able to answer hard questions before the switch is flipped and the delivery machine kicks into action. How does it create value? For whom? How does it generate revenue? Where does it incur cost? How does it stay compliant? How can it be defended against competition? How many customers does it need to break even? At what point to do we stop? A shiny deck just doesn't cut it any more.

Hard Questions

I set up Infinite Sidequests to explore the space between the idea and the delivery. I am fortunate to have had a number of people give me the latitude to try things out with their organisations and initiatives, and to be willing to deal with the ambiguity and uncertainty that invariably surrounds such work. I wanted to figure out what could be done to give new products and services the best possible chance for success before they are commissioned. I wanted to answer questions such as: How do we establish and maintain coherence across different groups, teams and functions? What can we do today to de-risk the proposition? Do we have a fighting chance of solving the customer's problem? What evidence do we need to see to be convinced that this idea has legs? What options do we have, and how do they compare? What's our first step?

Click Here

Unsurprisingly I learned that I alone do not have the diversity of skills and perspectives cover all this ground. But, it turns out that it is totally possible to form small interdisciplinary teams that can. And that's what I'm keen to do more of. So if you, or someone you know, is going through that stage between idea and delivery and feel like some backup would be useful, get in touch.