Skateboards vs. Cars Revisited

Nearly a year ago, one of my all-time favorite Agile coaches, Henrik Kniberg, published an article that I believe does an excellent job at explaining how engineering teams can leverage the concept of an MVP and ensure they are getting the core value out of Agile methods.  If you have not yet read Henrik’s article, I hope you will take a few minutes to do that first before continuing on here.

I am emphasizing here “engineering teams” because in this article I’m going to try to contrast the concept as it applies to true cross-functional product teams.

To be clear, when I say “engineering teams” I’m describing a team that’s either all engineers, or anyone else they have on the team is likely in a supporting role such as a basic product owner (versus a true product manager).

In contrast, a product team is comprised of a true product manager, a skilled product designer, and some number of engineers.

Now don’t get me wrong: many organizations just have engineering teams, with someone designated as product owner covering the Agile rituals around prioritizing and managing the backlog, but with little to none of the training or skills to be able to take on the much broader product management role. 

It’s often a similar story with the product designer.  They might have access to a graphic designer, but not the dedicated product designer skilled in user experience design, prototyping, user research, interaction and visual design that I’m talking about.  

In any case, if the team doesn’t have a true product manager or true product designer, I generally point them at Henrik’s article and tell them I think it’s the best they can do.

But if this is a true technology-powered product company, then I do argue to them that they can and must do better than this.

So if you’ve got an actual cross-functional product team, with a skilled product manager and product designer working side-by-side with the engineers, then how would you tackle this work?

In Henrik’s example, the team is working to simultaneously determine the right product to build, and at the same time to build that product.  And they have one main tool at their disposal to do that: the engineers.  So what you see is a progressively developed product, with an important emphasis on getting something we can test on real users at each iteration.

Henrik is emphasizing that they are building to learn, but they are doing this with the only tool they think they have: engineers writing code.  If you read carefully, Henrik does mention that the engineers don’t actually need to be building products – they could be building prototypes, but with most teams I meet, this point is lost on them because they don’t understand that there are many forms of prototypes, most of which are not meant to be created by engineers.

Now let’s consider the first principle I spelled out in the Beyond Lean and Agile article.  If you haven’t yet read that article, please read that now otherwise the following may not make sense.

The first principle is about tackling the risks up front, before we actually use our engineers to write a line of production code.  Rather than the relatively simplistic notion of a skateboard/earliest testable iteration, we dive deeper into the risks and explicitly consider value, usability, feasibility and business viability.  

Then, based on the areas we consider at risk, we pick the right tool or technique for the job (it’s beyond the scope of this article to describe the many techniques, but I will point out that there are four main types of prototypes), and decide whether it should be tested qualitatively or quantitatively.  And we test not only with users and customers, but also with the other members of our team, and the various impacted parts of our business.  

This is product discovery.  We’re working to figure out the right product to build.

The product manager and product designer drive most of this discovery activity, and the designer creates most of the prototypes we’ll need to tackle these risks.  And the engineers are included at every step of discovery, both to weigh in on feasibility of the proposed solution, but also and most importantly, to help improve the solution itself.  

It’s not that we couldn’t use the engineers to create the learning iterations like Henrik is describing, it’s just that it would take dramatically longer (in my experience, at least an order of magnitude) and yield substantially more waste, not to mention the opportunity cost.

A medium to large sized piece of work in product might need on the order of 5-15 iterations before it is working as well as it needs to (sometimes referred to as “time to money”).  

If all of those iterations are done using engineers and each requires releases to production, we’re probably at several months if not years of elapsed time, assuming management or the team hasn’t lost patience.  However, if we can do those same 10-15 iterations in a week of discovery, we’ve reduced our time to deliver the right solution (defined as both building the right product and building the product right) to our customers from months to days.

I’m also trying to make one other point with the discovery/delivery conceptual model you can see in the graphic above (at the risk of throwing too many points at you at once, but I think it’s an important one). 

Once we know the product we need to build, the engineers not only need to build and deliver that product, but they need to do this in a way that is scalable, performant, reliable, and maintainable, and in many of the companies I work with, they are at considerable scale, and this is not so easy.  Certainly not the kind of thing you would nonchalantly revisit every sprint.

The engineers really need to know it’s going to be a car before the engineers can come up with a suitable architecture up to the task, and they may in fact choose to implement this architecture with a different delivery strategy than one designed to learn fast. 

For example, they may end up building and testing out a set of micro-services (you can think of this roughly as the tires and the engine of the car) and then more of the front-end experience later in delivery.  We still want to avoid big bang delivery, but again this is up to the engineers and does not need to be a delivery strategy optimized for learning – that’s what discovery is for.

There is also an important second-order effect of doing product discovery as I’m suggesting here.  As the risks are tackled in discovery and the necessary delivery work becomes clear, that delivery work progresses much faster than it would otherwise. 

You’ve probably heard the old expression that “a problem well-stated is a problem half-solved.”  When the engineers are able to play with a prototype created in discovery and ask questions and identify missing use cases, then if and when we decide to actually build a robust implementation of this solution, that delivery work can proceed much faster, and without all the expensive and time-consuming delays and detours.

Henrik’s article shows how to get the value of basic Agile – and that’s no small feat as many teams are not yet getting this value.  What I’m trying to show is how strong cross-functional product teams have moved beyond Lean and Agile to tackle risks up front; solve hard problems for our customers and our business through collaboration between product, design and engineering; and focus on business results and not just shipping features.

Note: Thanks to Jeff Patton for his thoughtful comments on a draft of this article, and to Henrik for his many contributions to our industry.