Time Management > Task Management

I recently had an interesting insight, that upon reflection, may actually be a real-world example of a Minimum Valuable Problem issue.

A few months ago, a CEO of an early-stage company was asking me for feedback on the idea of adding “task management” features into their MVP product. My feedback was: “Don’t. It’s a super-crowded space, and nobody is close to getting it right. You’ll just create confusing overlap with existing tools that your users already use”.

The “nobody is close to getting it right” was based mostly on intuition, driven by more than a decade of experience with various tools. But at the time, I could not articulate what is it exactly that everybody is “doing wrong” or what “getting it right” may look like. I believe I can now.

Serendipitously, as I was getting ready to write this piece, I came across this one-sentence post by Jeff Weiner:

Jeff W

What most tools often miss is that what we really need help with is managing our time. Successfully managing our tasks is a byproduct of successfully managing our time. We cannot successfully manage our tasks if we’re not successfully managing our time, because, guess what, if we don’t have time to do the work, we cannot get the task done.

I think the folks at Plan, which I’ll get to in a moment, got it 100% right, arguing  that a big part of the problem is the direct replication of physical tools into digital tools:

“We’ve taken the solutions that worked in the 60s and 70s — paper to-do lists, desk calendars, notebooks — and replicated them online and on our phones. If you want to try to “get organized” today, it takes a ton of manual effort, discipline, and, most importantly, time to do it regularly.”

And I’d argue that the same applies to more professional tools such as the Gantt Chart (invented circa 1910) and the Kanban Board (developed as part of the Toyota Production System between 1948-1975).

As we break away from the “production line” type of tasks, and tackle more open-ended problems that require experimentation and creative problem solving, our time becomes our scarcest resource and the hardest one to manage.

Fortunately, there are some promising signs that this schedule-based, rather than task-based, approach is starting to gain traction through some early innovators in the space.

Plan gets at it from the task end. Giving you a side-by-side view of task lists and your calendar, allowing you to actually schedule time to do the work needed.

plan.png

Worklife gets at it from another non-trivial use of our professional time – meetings. Again, giving you a side-by-side view of your calendar and scaffolded meeting notes view, which makes it easier to track agenda item, assigned tasks and decisions, especially across recurring meetings.

hero-devices

Now if only they could be mashed together into a single tool for managing both tasks and meetings… then we would have a solution to a truly valuable problem.

 

 

Advertisements
Time Management > Task Management

Minimum Valuable Problem

Product Management digital newsletters are usually a good resource for more general management and leadership content. Since after all, regardless of our title, we are all product managers: we are tasked with solving a portfolio of problems to a diverse group of stakeholders, using our unique skill sets, through a set of services that we provide.

This summer, all the ones that I’m following on a regular basis seem to have experienced a disappointing drought, which has finally come to an end with this piece referenced in Pivot Product Hits by Scott Sehlhorst:

Minimum Valuable Problem

Minimum Viable Product (MVP) is a commonly used term in lean product development, which refers to “the least you can do” before shipping your product to market. Since the most critical learning, from a business perspective, happens when your product meets the market – aim to get to that milestone sooner rather than later.

MVP is typically discussed through a functionality lens – the minimum amount of features that we need to build in order to have a viable product.

Scott thoughtfully calls out a big challenge with this approach: since it’s an inside-out approach, it doesn’t give us any guidance as to “what is enough?”, increasing the risk of building too little or too much.

Instead, he proposes an outside-in approach: rather than asking what is the minimum viable product that we should build, we should be asking what is the minimum valuable problem that we should solve.

Asking that question from an outside-in, customer-centric perspective, increases our chances of building something that is of value to the customer, as measured by the problem that it is solving for the customer. If it’s only solving half the problem, it’s not that valuable.

In Scott’s words:

The minimum valuable problem is one you completely solve.
You may only solve it in a very narrow context or scope.
You may only solve it for a small group of users or a subset of your ultimate market.
You may only solve it adequately, without creating a truly competitive solution.
But for that one customer, in that one situation, you have completely solved it.

 

Minimum Valuable Problem

N Squared

Azeem Azhar’s “The Exponential View” is one of my favorite weekend reads. A few weeks ago it contained a link to Amna Silim’s “What is New Economic Thinking?“. Buried in its reference section, I’ve found this gem by Paul Ormerod:

N Squared

N squared stands for Nudging * Networks.

The first part focuses on “Nudging” – the kind of gentle behavior change interventions based on behavior science (rather than standard neo-classical economics) popularized in books such as Thaler and Sunstein’s Nudge.

The meat of the paper focuses on “Networks” and in particular, human networks. It explored the implications of a very interesting assumption:

“Many of the decisions we make are based not so much on the independent, rational calculation of the costs and benefits of different actions – the mode of behavior posited in economic theory – but on observing and copying others”

Ormerod provides a very easy-to-understand explanation of the behavior in a random structure network using the model developed by Duncan Watts.

The outcome of the model is best summarized by the following quote (and graph):

“Systems of interconnected agents whose behavior influences each other are both robust and fragile. These are key words. Most of the time, the system is robust to small disturbances and these do not spread very far. But occasionally, the system is fragile, vulnerable to exactly the same size of shock that usually it is able to contain…

…  The common sense causal link between the size of an event and its eventual impact is broken. “

cascade.png

One of the immediate implications of that outcome is that:

“networked systems bring problems when it comes to measuring impact. What worked and what did not work? And why? A great deal of policy evaluation is carried out paying little or no attention to the potential impact of network effects. But if these effects are significant, studies that ignore them can generate misleading results. A successful outcome may arise not because of a nudge factor, but because of imitation across the network. The risk is that success can be mistakenly attributed and policymakers left puzzled when a similar policy leads to failure in a different context.”

As a final note, Ormerod introduces two additional network structure archetypes, “Scale-free” networks and “Small-world” networks, to show how an intervention strategy that works in one, may not work in another.

Good papers leave you with questions that you’ve never even considered before, that this was definitely the case for me here:

  1. What type of network archetype best describes companies?
  2. Does the archetype change as the company scales and the dynamics of the connection changes?
  3. What does 1+2 mean for corporate governance and more specifically, driving change inside companies?
  4. Given that many employees are tasked with enacting change in networks, how should the now common “accountability to impact/outcomes” mindset change?
N Squared

The OS Canvas

The fantastic piece of thoughtwork by the folks at The Ready:

The OS Canvas

OS v2.0

As Aaron defines it, it is his 2nd attempt to describe complex organizations through simple frameworks in the most comprehensive way possible (the first being the responsive.org manifesto).

Visually, it’s inspired by Alexander Osterwalder’s Business Model Canvas

From a content perspective, while drawing from the works of dozens of people, the strong influences of Frederic Laloux’s list of structures, practices, and processes in Reinventing Organizations is clearly noticeable.

The framework decomposes the organizational operating system into 9 components:

  1. Structure & Space
  2. Authority & Decisions
  3. Information & Communications
  4. Policy & Governance
  5. Purpose & Values
  6. Meetings, Rhythm & Coordination
  7. Strategy & Innovation
  8. Resource Allocation, Targets & Forecasts
  9. People Development & Motivation

oscanvas.png

Towards OS V3.0

I view this framework as a huge step forward from v1.0 in three major fronts:

  1. Visual representation – the canvas leverages the spatial arrangement of the content to make it easier to see both the system and its parts at the same time
  2. Content – this iteration seems a lot more comprehensive and captures many organizational elements that were missing in the original manifesto
  3. No-judgement– leaving each of the boxes (components) blank, leaves room to study any potential permutation, without judgement, seeing how small changes may affect the interactions between the different pieces and the whole.

While this framework is a huge step forward, its structure also clarifies the value that it is yet to unlock.

The simple 3×3 layout implicitly suggests that “all parts of the organizational OS were created equal”. I strongly believe that this is not the case, and there’s some directional/sequential relationship between the different component. For example, the organization’s purpose and its beliefs about human motivations seem to be deriving / constraining some of the other components, while the inverse seems to make less sense.

The canvas idea gives us the opportunity to capture not only what the different parts are, but also, to some extent, the way they interact, which a critical attribute of the organizational system.

Lastly, I suspect that if we follow the intent to capture interaction as part of the canvas to its conclusion, we’ll discover that some of the initial “pairings” (all boxes are currently in “X & Y”  or “X, Y & Z” format) don’t make sense anymore, and need to be reshuffled in order to make the interactions more apparent.

Looking forward to v3.0 from Aaron and team, so I can compare it to my own.

 

The OS Canvas