5 Product Development Questions

A little kanban with your morning coffee.

I like using kanban boards to think about product development questions. I like kanban boards because they are a complete blank slate. You can model Scrum with a kanban board, or you can model a typical d-thinking process. Or roll your own.

And when it stops working — provided you aren’t knee deep in a digital tool — you can just change it.

Here are a couple questions from this morning’s brainstorm.

Question #1: What is Done?

Some systems help us track the work. Some systems help us visualize value delivery. Done is an elusive concept. Tools tend to be designed around tracking work, instead of tracking our progress towards outcomes. We have trouble visualizing these in parallel.

How we solve this problem — who sees what and how often — has a profound impact on our product development teams.

Question: Do Sprints obscure the actual work?

What do we optimize for on the left? How about on the right? Why do these feel different when they could be similar? The option on the right feels nebulous. Who owns what? How does this work with Sprints? The option on the left feels overly restrictive and too siloed.

But in a quest for efficiency, many teams opt for the left option, yet track that work in a separate system. Why? Scrum focuses on the dev’s In Progress. Are you letting your tools and process run your team, or the other way around?

Question #3: Is this a pull system?

Work moves from left to right… right? Well not really. This is a pull system. An unmet need (a customer “order”), triggers the need to produce something until that need is met. Are you pushing or pulling? What constitutes an “order”?

In a push system, we’ll focus on a big list of projects that have to be moved through the system (pushing features on to customers). In a pull system, we’ll focus on triggering work to deliver a specific customer need.

Question #4: Should we include downstream steps? Why? Why not?

Out of sight, out of mind! Right? Marking the item Complete in Jira does carry a certain sense of satisfaction, but there is more to go. At this point, the work has no value. No value has been exchanged. Consider why you do/don’t picture all of the downstream steps. It’s messy, for sure. But does it need to be that way?

Question #5: What constitutes a team?

Is this one or two teams? It might be more convenient to view this as two teams, but in reality it is one team. How does calling it two teams help us?