How to Solve Problems as a Team

In building the design practice at Appiphony over the last few years, I’ve researched quite a few methods and frameworks. I’ll look at anything that smells like it’ll make us smarter or more efficient…books, blog posts, workshops, and so on.

But when I picked up Max Shron’s Thinking With Data, it was more or less on a lark. I was curious about data science and it looked like a friendly introduction; I didn’t expect to bring anything back to my team.

Good news: I was wrong. Max’s book contains one of the most useful things I’ve read this year, and it’s got nothing to do with numbers. It’s a problem-solving communication tool he calls CoNVO, and you use it to structure conversations about the problem to bring others up to speed. “CoNVO” is a mnemonic:

• COntext: What’s the setting in which this problem exists?
• Needs: What specific items do we know of today that need to be addressed?
• Vision: What’s the initial concept of how we plan to solve the problem?
• Outcome: What does the future success state look like in which the problem is solved and the organization has adopted the results?

If you’ve ever spent time “level setting” a colleague about a new issue your team is facing, you’ll benefit from this approach. Moments like this happen almost every day for me, whether we’re talking about a small bump in the road or a major new initiative. It reminds me of a good chef’s knife: you can tackle almost anything with it, so you end up reaching for it all the time.

An Example

Here’s a quick example, illustrated for effect.

Context: we’re out in the wilderness and there are no towns for a few miles in every direction. We’re coming down a hill, approaching a stream that empties into a lake.

Needs: we’re getting tired, and we’re a bit thirsty.

Vision: there’s a dry, level area on the other side of the stream. We can probably step across where it’s shallow, but once we get closer, we might decide to go a little further and walk across the makeshift bridge.

Outcome: with our camp set up, we’ll have water from the stream, and a nice place to rest.

This structure works just as well with your next multimillion dollar initiative; just substitute in different details. If you’re situation has specific metrics associated with it (e.g. success equals a 20% increase in revenue), place those in the “outcome” section.

The “outcome” section is my favorite, in fact, because that’s how you open the door for team collaboration. Separate the “why” and the “what” from the “how.” Whatever you’re trying to accomplish, emphasizing the goal instead of your solution leaves room for others to bring you amazing ideas.

Still Defining the Problem After All These Years

I stumbled across this introductory Pascal book at a relative’s house and was intrigued by a brief section called The Phases of Development, which breaks the task of programming into four phases:

1. Clarify the problem requirements.

2. Design a program strategy.

3. Specify critical data structures.

4. Write the program statements.

I particularly love some of the quotes on problem clarification:

Surprisingly, clarification of the problem is a major phase of the process. It would seem reasonable that a clear and precise statement of the problem would be given but in fact this is rarely the case and more programming disasters can be blamed on failure in this regard than any other.

Today’s coding skills won’t be relevant in thirty years, but we’ll still need to clearly define the problem.