Bye steering group - Hello discovery team!

Disclaimer: For pedagogical reasons, this article contains a few over-simplifications and generalizations. But I ensure that no steering group where harmed during the creation of this article.

The role of the steering group

In most traditional companies involved in some type of product or system development, the main vehicle for research and development is a project. A classic stage-gate project with a budget, a time plan, a scope, a project manager and a steering group.

The steering group typically consists of a couple of senior managers - like the R&D manager and the PMO manager - as well as a product manager and key stakeholders from the business side. The steering group may also include some kind of process/quality person and a project coordinator, but they rarely have enough authority to actually influence the project significantly.

There are many definitions of a steering group out there, but the main function of the steering group usually boils down to making project decisions and supporting the project manager. The decision making is generally associated with approving some kind of fundamental change of the project - like increase the budget, add resources, change the scope, move deadlines, pass/fail milestones, change project manager, or even stop the project.

So far so good...

Problems with steering groups

Having an active steering group is generally viewed as something positive. But having a traditional steering group in a development project with a fair amount of uncertainty (which is the case for most R&D projects), may however be associated with a number of problems:

The steering group wants predictability - Having a sense of control seems to be the most fundamental need of the traditional steering group, in my experience. They want to know exactly when the project will be finished, how much it will cost and how much better things will be when it is done. But working in a volatile environment, with many known unknowns as well as unknown unknowns, predictability comes with a cost - innovation is sacrificed. "100% predictability = 0% innovation" as Henrik Kniberg puts it.

Lack of up-to-date real world experience - The members of the steering group are generally too far away from where the action happens, i.e. the engineering teams and the customer sites. And frankly speaking, it has usually been quite a while since they did some real hands-on work ("real work" meaning programming, testing, customer research etc.). Instead they are busy attending countless meetings, reading/writing status reports, creating budgets, doing performance reviews and other typical management stuff. Hence, they lack relevant and up-to-date real world experience (including technology , modern ways of working, customer insights etc.) to guide and support the project in the best possible way.

Opinions over facts - I dare to say that most people base their decisions on opinions rather than facts. It's just human nature. This is also true for steering group members (most of them are humans, after all). And in the typical corporate setting you need to be aware of the HiPPO principle and how it may bias the decision process (HiPPO = Highest Paid Person's Opinion). In addition, the steering group's main source of "facts" are status reports - i.e. oversimplified, traffic light-based reports written by a project manager with the intention to give an impression that progress is good enough so the project team can continue to work undisturbed.

Too much focus on the the "iron triangle" - A steering group puts most of their focus on the iron triangle, i.e. cost, time, scope and quality, rather than how to maximize customer value and learnings. Don't get me wrong - cost, time and scope are often of utmost importance, but they are generally overemphasized compared to how to achieve the wanted effects and maximize the value of an R&D project.

Slow decision process - The decisions of a steering group are typically big and infrequent, where an R&D project rather requires small and frequent decisions.

Bugging the project manager - To satisfy the steering group's hunger for status updates and sense of control, they request a lot of information from the project manager. As a Project Manager, you often find yourself spending 80% of your time providing the SG with status reports, and 20% on actually supporting the day-to-day work in the project.

Hello discovery team!

If running projects guided by a steering group isn't the answer, what to do? Well, I would like to see more product companies working with continuous product discovery instead of running temporary start-stop projects with fixed time plan, scope and budget. Product discovery is the art and science of rapidly building knowledge about the business processes, the users and their needs, as well as understanding technical feasibility. Product discovery is an open-minded, curious, innovative, communicative and cross-functional undertaking.

A product discovery team typically includes the product owner, UX designers, developers/architects and business people - who all work closely together. "Product discovery is a team sport." as Roman Pichler says.

My best tips for successful product discovery

Get out of the building - Go to gemba. Meet real users in their natural habitat. That's the only way of understanding their real needs.

Hypothesis driven - Consider all ideas as fantasy until they are validated with real word data.

Use appropriate tools and models - Use visual tools, mental models and process frameworks to facilitate discussions and create transparency. For example Business model canvas, story mapping, impact mapping, discovery sprint, jobs to be done, Lean startup, journey mapping etc.

Dual track agile - Discovery does not end where development begins. Product discovery is a continuous undertaking and is preferably perform in parallel with product development. See the product discovery team as an agile team (with a backlog, a product owner and a backlog) following a lean/agile process like Scrum or Kanban - side-by-side with the development team.

Follow-through - Continue to work with discovery throughout the full life-cycle of the product. Consider giving a mature product a mid-life kick or extend the lifespan of a sunset product.

Wrap-up

In my experience a traditional steering group does not give the support a project needs. Product discovery teams would provide way better support and significantly increase the likelihood of success. So ditch the command and control steering groups and establish innovative product discovery teams across your organization instead.

Comments, thoughts? Please share your view below! :-)