Until a few days ago I hadn’t heard of Coda and its founders, but that changed when I came across their approach to framing problems and asking questions. Coda is a document creation and sharing platform, Shishir Mehrotra – Co-Founder / CEO and Matt Hudson – founding product manager and now Head of Growth – share the techniques Coda uses to frame problems in this great article.
Mehrotra and Hudson describe ‘framing’ as the process of breaking down a problem into a set of choices, tradeoffs or options. As product managers we often start with a problem to solve, and it’s important to frame the problem in such a way that it feels solvable or constructive at least. Like the American philosopher John Dewey stated “A problem well stated is a problem half solved”.
In the Coda article, Hudson talks about an example from his time at YouTube where he was part of internal debate about whether to “link out” YouTube to external or platforms or not. Hudson explains: “At an offsite to resolve the debate once and for all, I presented an alternate framing to break the standstill. Instead of thinking of this question as “link out” vs don’t, what if we thought about this as the choice between consistency and comprehensiveness? His real-life example illustrates the power of framing a problem in such a way that you’re creating ‘a way out’, working through a problem in a constructive way, and coming to a solution or a decision. Mehrotra and Hudson go on to list some powerful benefits of good framing:
- Providing a common language through which a problem can be shared and understood.
- Find “the right question” whereby a problem gets distilled to the one question that creates a clear path forward. I recently reviewed “Questions are the Answer” in which Hal Gregersen covers the power of questions that rotate one’s perspective on a problem. In the approach of Mehrotra and Hudson this is where the “eigenquestion” comes in.
Finding the “eigenquestion”
The eigenquestion is a word made up by Mehrotra and Hudson, derived from the linear algebra concept of eigenvectors which help reduce dimensions after ensuring most of the key information is maintained. If you have 10 dimensions of points, the eigenvector points out a single dimension that will capture the majority of the points. From a questioning point of view, the skill here is to reduce 10 questions to the single most important question. The truth is that there’s never one right question, but the idea is that one key question if answered, it will likely answer any subsequent questions too. To bring this to life, Hudson shares a version of an interview scenario he uses when talking with job applicants:
- How safe is the device (safe enough for humans vs not)?
- Where the primary cost is (is it in operating the device or purchasing them)?
With this info, they were able to describe four very different go-to-market paths:
- If the device is safe enough for humans, but is more expensive to deploy than operate, then it should probably be stationed at a fixed set of locations and run much like an airport system.
- If it’s similarly safe, and is cheap to deploy but expensive to operate, then we should enable everyone to have a device like this in their homes, workplaces, etc and then just use them when they find the use case valuable enough. In this way, it might be more similar to “fax machines.”
- On the other hand, if the device is not safe enough for humans, but is still cheap to deploy, then we probably shift this plan and think of it a bit more like an upgrade to fax machines to be able to transmit 3D objects.
- And finally, if it’s not safe for humans, and expensive to deploy, then perhaps we are building a freight network.
Main learning point: Whilst it might take me some time to master the skill of reducing loads of questions into one or two key ones, the concept of “eigenquestions” is a valuable one. It helps in framing a problem, bringing it back to its essence and using one or two critical questions to forge a path forward.