Category: Debt

Mental Model Minute: Seven Levels of Authority

Posted on Posted in Debt, Uncategorized

We are all growing and learning as professionals in a collaborative workspace. It can be helpful to take a step back and look at different models of individual and team behavior. A “mental model minute” takes just a moment to describe a different view on how to perform or interact better that we can react to and learn from. I will post these from time to time. If you know of mental models that have helped you, post!

One of the hardest things to navigate in a collaborative workplace is whose decision something is. This is where the “Seven Levels of Authority” from Management 3.0 by Jugen Appelo model comes in handy. His model is about authority definitions between a manager and their team. I have found it useful between individuals or across teams as long as you clearly define who is playing each role.

The Model

Too often in decision making we think it’s “your decision” or “my decision”. However, actual decision-making authority is way more nuanced than that.

Seven Levels of Authority

At one end of the model, the decision is 100% “mine”. E.g. as the manager, I am telling you what we are doing. I have most often seen this level arise (in healthy organizations) in situations where information is highly protected such as a firing decision or where risk is high such as PCI compliance.

On the other end, the decision is 100% “yours”. E.g. as the team, the manager has delegated the decision and has no need to be further involved. I have most often seen this in implementation details or technical details from a non-technical manager/product owner.

In the middle of the model is “Agree”. In other words, the decision is made jointly between the parties. The biggest risk with “agree” decisions is they don’t ever actually get made. To mitigate that it is helpful to put an artificial process like dot voting or a timebox in place.

Most decisions fall on one side of this or the other.

With “Sell” and “Inquire” the decision is made by one party but the other party wants to be informed after the fact. With “Consult” and “Advise” the decision is made by party with the other party giving input before the decision is made. In all these cases, a party has the clear decision-making authority. For example, in “Consult” the decision is made by manager with input from the team beforehand. An example of this may be hiring decisions. With “Advise” decision it is often important for the manager role to publicly support the decision after the fact for the team to feel like they are actually allowed to make the decision until norms are established.

How to Use it

The other night, my husband’s phone died. He went out and bought a new one. I asked him how much he spent on it, and he deflected the question. I got angry at him and he was upset with me. Why? We had talked about how a phone is critical for both his home and work life. Whereas I can run with something barely functioning for a surprisingly long time, he spends 80% of his work time on the phone. His phone had ceased to function as a phone. We had talked about how it was urgent he get the phone replaced. We even agreed I would single parent bedtime so he could get to the store before it closed. So why was I upset? Because it was not a simple “his decision”. In this case, think of me as the manager (yay marriage). He thought this was a level 7. I had fully delegated the decision to him. I thought it was a 5 or 6. I wanted to hear about the decision after the fact and the details. In a 20-year relationship, we can be dialed into the difference between a 6 and a 7. In most work situations that level of detail isn’t necessary. But knowing where that difference in expectation arises allows you to adjust for the next time.

In my last gig, I had a business partner who was going to use the app my team was developing. We would have discussions about the requirements of how the application would make her life better. At various points when trying to decide how something was going to work, I would be very up front with her about who got to make that decision. “That is a technical implementation decision. So I can go talk to the team about options, but we may be limited here” when we were more at the 5/6 area. When we are more at a 2/3 I would say “We can make that happen for you. Here are the trade offs but it is ultimately your decision as the user.” It helped give her clarity on where we were in the project and what the outcomes would be.

I have a friend who uses this technique at work. When she is describing a course of action she is planning on going down, she will end it with “but my boss can always tell me I have other priorities or to do it differently”. Her boss is always in the room in these situations.

The Next Right Thing

Posted on Posted in Build Things People Want, Debt

You’ve seen Frozen 2, right?  I mean, if your household is anything like mine, it’s playing on repeat in the background as children scramble, color, and fight.  Admittedly, I have only sat and watched it end to end once.  Still, there is one part of the movie that stick out to me and, I think, has a lot to teach us about business decision making and product management.  Warning, movie spoilers ahead.

After discovering a lot of hard truths about her own grandfather’s culpability in a generations long unnecessary war, and the apparent loss of her sister to the ongoing tragedy (who said children’s movies were lighthearted), Anna is stuck.  She must standup, dust herself off, and determine what to do now.  She sings a hauntingly beautiful song about grief and figuring out how to go on.

I don’t know anymore what is true
I can’t find my direction, I’m all alone
The only star that guided me was you
How to rise from the floor?
But it’s not you I’m rising for
Just do the next right thing
Take a step, step again,
It’s all that I can to do
The next right thing
I won’t look too far ahead
It’s too much for me to take
But break it down to this next breath, this next step
This next choice is one that I can make

The Next Right Thing, Frozen 2

Often I find myself at an impasse.  Maybe it’s not the fate of the world and the righting of generations of wrong sitting on my shoulders, but the pressure does affect me none the less.  Sometimes it is something stupid simple like how a UI interaction should work.  More often it is the juggling of priorities.  My team can only tackle one thing right now, here is the list of problems facing us, what is the next right thing.  And there it is, the song pops into my brain and wiggles itself down into my toes.

These are the moments I take a step back, like Anna, and see what inspiration sticks me.

  • Can I easily summarize the problem?
  • What is the root cause of the problem?
  • Who else can I talk to about this problem?  Do we agree on the same problem, or do they have a different perspective on it?
  • Why do I feel like this is a real problem?  What are the consequences of not addressing this problem?  Who will be affected and how soon if the problem persists?

If you have ever read anything I have written or listened to one of my talks, this will sound like pretty Jennie-standard-faire.  Find the problem statement and the solution will become apparent.

The struggle I have when I train and talk to other product managers how much we want, and sometimes need, a structure for this kind of decision.  Instincts and experience are not scalable.  So, we must find some balance between structure that helps in decision making with the instincts that allow good decisions to be made quickly and with a decent right/wrong percentage.  Over time these tools can become second nature.  Here are a couple of my favorites:

Prioritization Matrix:

Draw a 2 x 2, label one axis with affect measures such as:

  • Urgency: How quickly someone will feel the affect
  • Density: How many people will feel the affect
  • Impact: Significance of the change to the people affected
  • Importance: The importance of the people feeling the affect to your organization

Label the other axis with an effort measure such as:

  • Level of effort: How much effort it will take your team to address it
  • Feasibility: Likelihood the problem is solvable
  • Isolation: Ability to solve the problem without having to solve all other problem (or a measurement of dependencies

Once you have your problems laid out in your matrix you can easily determine which to action on by using this rule of thumb:

Prioritization Matrix

Tell a Story

Find a friend and tell them the story of your problems.  Have them keep track of how many times you bring up the same problem in your narrative of what is happening to your users.  Generally, that is the problem your instincts are telling you that needs to be solved first.

Anna leaned towards the “tell a story” method.  She looked around at her situation and said, “here is what I see going on, here are all the pieces of what I observe.” And from there she was able to figure out the next right thing without getting too focused on what comes after that step.  Sometimes it is that trust in ourselves that we need to be growing.

Build Things People Want

Posted on Posted in Build Things People Want, Debt

When I started at my current company, the mandate I was given by the developers was to help them build things people want.  It is something I have heard over and over again from developers throughout my career.  And frankly, it’s a goal that the organization and the developers should be aligned on.  The business wants products that sell.  The thing that most undermines a good development team is when they build something that never gets sold, used, or heard about.  But too often, organizations don’t know how to do that.

I am going to spend this post breaking down the problems with “building things people want” that I have run into.  I will spend future posts talking about strategies on how to address each of those problems.

People – The Problem of Who

There is no product that can meet all the needs of all groups of people.  There are hundreds of different kinds of chocolate bars and candies because they appeal to different people, at different price points, at different times.  Today I want a Hershey’s Kiss, tomorrow I want a Lindt Truffle.  Different products met the needs of different target markets and demographics.  So before you can design your product you have to understand who you are designing it for. 

Too often I have seen this turn into a marketing exercise of creating personas.  And the persona always turns out to be a woman named Jennifer who is between 25 and 45 and likes walks on the beach at sunset.  Personas are great, don’t get me wrong, but I am looking for the problems the persona has that I can solve.  I don’t just need to understand demographics, I need to understand what that group is trying to do, why it isn’t working for them right now, and what I can do to resolve those problems.  As with most things, I want to start with a problem statement.  Then I need to validate the problem statement against real users.  Am I solving a real problem?  Have I gotten the problem statement right or am I making assumptions to fit the product I want to build?

Okay, now I have a ‘who’ but there is another really important question that goes along with that who: how many of those ‘who’s exist?  Am I building a product for one very passionate person?  Do I have a robust market segment?  Is it a segment I have access to and legitimacy with? 

Want? – The Problem of What

Understand the problem statement means I can start to find solutions to help that target market.  Here is the truth, though, no organization is capable of solving every problem.  Too often companies spread themselves too thin.  Just because they find a problem within a target market that they have deep understanding of, access to, and legitimacy with doesn’t mean you have the organizational alignment, focus, and depth to be successful at developing the product, bringing it to market, or supporting it organizationally.

The first set of questions around ‘what’ are questions of product market fit.  These are a natural extension of the ‘who’ questions we asked above.  How many people want this solution?  What is the competitive landscape?  Is the market big enough to justify the cost of entry and product development?  Can I get enough market share to justify the ongoing cost of sales and support?  How are competitors likely to respond?  What kind of unique differentiators can I offer?  How sustainable and unique are those differentiators?  Is my solution better enough than what my potential buyers are using now?  What are the switching costs of buyers?  What market pressures are their such as buyer power and distribution models?

The problem of ‘what’ includes not just what the solution looks like in the initial build and the market, but how this new product fits within your company’s identity.  Does this product fit with your long term vision of who you are as a company?  Will it support or detract from current offerings?  Is it easy to scale with your existing staff?  For example, if you been mostly building web applications and now you are going to build a mobile application, what impact does that have on your organizational vision and alignment? 

Build Things? – The Problem of How

Let’s say you have something to build that you know people want.  Even better than that, it’s something that organizationally fits with who you are.  Congratulations, now you are at the problem of ‘how’.  We are going to build something, we know who it is for and what we want it to do for ourselves, our clients, and the organization.  This is the point where I take off my marketing hat and put on my developer hat. 

The first set of questions I have is how we want to organization the development of the product.  How much effort?  How quickly do we need to get something to market?  How thin can our first cut of the solution be in order to start getting feedback?  What kind of feedback loops can we build into our development process and what customers can we engage in that process?  How will we know when we have something complete enough to release?  How do we plan for multiple iterations?  How do we communicate timelines and expectations to stakeholders that is a proper balance of managing expectations and giving ourselves room to pivot?

The second set of questions I have is how we approach the product technically.  What tech stack are we going to use?  How does this fit into or otherwise enable our overall architectural direction?  What tech debt should we attempt to address during this process?  What unaddressed or unaddressable tech debt do we anticipate facing during this process?  Who are the best people for the technical challenges?  What information do we need about the system do we need before we start?  What is our ubiquitous language?  What competitor examples or market concepts can we use as a foundation?

Build things people want seems like such a simple statement on its face.  However, it generates a lot of very important business questions for me.  In some future posts I will spend some time thinking about different strategies I have used to answer some of those questions.

True Confessions of a Product Manager: Project-itis

Posted on Posted in Debt

I have fallen into the trap. It’s such a pretty trap lined with certainty and speaking to underlying control issues. But it is still a trap.

I have, I admit it, gotten stuck in Project Thinking. This is my confession and promise to be better. This is not me entering into the great “No Estimates” debate. There are no winners there. This is a promise to recognize when I am working on a project and when I am working on a product.

What’s the difference?

A product is:

A living application that is defined by engaged and potential customers, their pains and gains, and the contributions to the business. A product’s development should be driven by a long term vision that is outlined in a roadmap with room for iteration and learning.

A project is:

A timeline driven goal to deliver a feature or set of features usually defined in a statement of work or contract at the beginning of the project. A project is successful if it is completed on time and on budget while satisfying the requirements.

If is too easy, when putting together a roadmap, to fall into project thinking. The business and clients want to know not only what new features a product will have but when they will get to be able to use them. Answering those two questions results in a natural impulse to put together a project plan. An impulse that must be controlled, but not eliminated! These questions need to be answered, but they need to include the context of the overall product vision and user feedback loop.

There are two articles that have contributed greatly the way I think about the way I see my responsibilities as product manager: Kyle Evan’s article Product Thinking vs Project Thinking for the Product Coalition and Sriam Narayan’s Products Over Projects on the excellent Martin Fowler blog. I was exposed to both of these blogs by an excellent software developer on my team to whom I will forever be grateful.

I saw that I was not seeing the product through the project, much like the not seeing the forest for the trees. In the building of the product roadmap, all I can see is the forest. However, in implementing features suddenly all I was seeing was trees. Everything about finishing a feature on time and the overall goals of the product were getting lost. This is Project-itis. This is where good product development teams become feature factories.

How to cure project-itis?

After spending some time reading through these articles and looking at my own ways of talking about our product, I realized the key was to know when we are talking about forests and when we are talking about trees. Because the forest is full of trees.

Yes, I know I am overusing that metaphor.

Maybe a visual will help.

A product is a set of features. The way that a product fits together consistently is two things:

  1. A long term product vision that is selective about which features to include.
  2. Room for tech debt, architectural improvements, honoring the campsite rule, and dev ops

The second of these is a subject for a different post.

Once I have a set of product features that support the long term product vision, I can prioritize them. Based on building an effective user feedback loop and product vision, I know which features need to be done quickly, which need more feedback, and what research.

When I open up a feature for the team that is the project. That is where good project life cycle management comes including ideation, market validation, solution generation, and release. This is where finding small slices to get feedback from users come in. This is where a project plan and estimates are useful. Focusing in tight on just that feature is a project.

If all we do is focus on the project, however, the product suffers. The trees don’t talk to each other, don’t work together, and there can be no forest.

Okay, so I really like that metaphor. It’s helping me climb out of the trap though, one tree at a time.