Once upon a time a client came to me and said, “We want to build a new capability on the website that does Magic Thing Here.” The client had a concept, some business goals, even a good idea of what the users wanted, and all we had to do was get started.
And I said sure, let’s get to work.
We sat down, had some meetings to bring me up to speed on the project, made some super-high-level sketches, brought some more people with technical acumen in, talked through it all, got to the point where it was time to bring the vision down about 10,000 feet so we could figure out what to build, and the project team hit a wall.
Hard.
And this was a frustrating experience for everyone – not just the people on the team, but also their managers, stakeholders, etc., because nobody’s happy and nothing’s moving and at least one person had a massive headache.
***
Its worth pointing out now that this wasn’t a one-time situation. It happens on almost every project team I’ve worked on that *wasn’t* a remodel-existing-capability project. If it’s new, jumping the gap from “high level idea” to “think we can actually build” has been a challenge.
***
So I sat down and I wrote down everything I knew about the project and then I started modeling what I knew.
There are lots of different ways to model an idea.
Maybe I created a SIPOC and some process maps to figure out what the difference between what we had as a product offering today and what we wanted to have as a product offering tomorrow would be.
Maybe I created a Capability Strategy Sheet to capture our users’ needs and business goals and then figure out how we’d measure them and move the dial.
Maybe I created a storyboard or, embarrassingly, acted out the actions the users in our personas were doing mid-meeting, based on our research.
Maybe I created a journey map of one individual external client’s perspective, so that we could identify pain points and eliminate them.
I may have even formed my fair share of Lean Startup hypotheses so that we could trim down to one specific problem to chase, and chase only it.
(Probably along the way I created a dozen really bad metaphors. Ask me about the chocolate bridge sometime.)
***
Teams get stuck. It’s not unusual, it’s not wrong, it’s not failure, it’s just part of the process.
We’re people, after all. We get just as stuck in decision fatigue and paradox-of-choice situations as our users do. In some cases, it’s because we have not-enough information, but in many, it’s that we haven’t found the right angle to apply to the information we have to make a decision.
When a team is stuck, the same analysis tools that we’d use with an unstuck team to validate a decision or argue for a specific approach will help us make a decision or choose an approach.
It may take multiple attempts and different angles, but it will eventually get things moving again.
And despite the fact that as we plan and plot we might feel like Wile E Coyote hatching plan after plan to take down the Roadrunner, we have one advantage he does not: we learn from our missteps, adjust, and get closer to the right course.
***
During one of these attempts to lasso the moon, we succeeded. To the team it felt like soaring into the air crossed with pulling our legs out of calf-deep molasses, but it’s forward movement. Suddenly things started making sense, a direction took shape, and we knew what to do next.
And we all lived happier ever after.
Until the next project, anyway.
