Just a little bit of help

One of the characteristics of Product Thinking is that it actually requires thinking. And thinking takes head space and time. And to be honest, taking time to think or re-think product decisions is hard. And most environments do not allow it.

We have production issues. A backlog full of things we think users are waiting for. Changing strategy, sometimes based on little more than a hunch. And many other time-consuming topics.

And meetings. So many meetings.

What this really comes down to is: most all of us who work in product could need a bit of help while we think. Not to replace thinking, but to support it at the right moments. This is exactly the problem I am currently trying to solve by building something around it. I have been experimenting with ‘Assisted Product Thinking’ or ‘Guided Business Goal Validation’ and want to share what that looks like.

Ever ongoing

From Objectives to outcomes

A typical flow from strategy to outcomes continuously translates goals into measurable feedback It sounds simple, but in practice it rarely is.

If you look at all the items that should be reflected in a product, you can see it is quite extensive. Strategy, business case, product vision and feedback with user needs, features, outcomes, jobs-to-be-done and many more tools underneath. The reason for this is simple: we need to make sure we are always building towards out goals.

To emphasise the amount of thinking power needed: all artefacts described above are dynamic. And changes in one will often effect the other. There can be many changes like a war, crisis, innovation or the latest shift in management that can have a big impact on our products. It raises questions like: How does this reflect our strategic goals? And how is this cascading into all other artefacts? And more importantly, who is keeping track of that?

We just need a little bit of help

In the past, whenever I tried to embed this cycle, it was often the first thing to be neglected when something happened. Or the work pressure for the responsible was just too much. Or when I, as Product Thinking consultant left. Or there were budget cuts or shifting priorities.

The reality is that when things change, all described artefacts need to realign as well. The effect of this is even more work, which require the right head space and time. Exactly the two things we usually do not have at that moment.

The only way to make this work is to automate it. Invisible when everything is aligned, and very visible when action is needed. Comparable to other parts of the domain like CICD and quality assurance. Not replacing people, but supporting them with the right signals.

Fundamentals check

The fundament of a product and its reason to exist is stated in things like the strategic goals, business case and of course the product vision.

If these align, we know the fundament is solid. Borrowing from CI/CD practises, we only need to know when they no longer align. Only then we need to take action and make sure to re-align them.

For example: due to decreasing budgets a products business case can change. Another example is that due to strategic re-alignment the target group shifts a bit.

These changes will often impact all from strategic goals to the product vision and eventually the features. In my current setup I re-validate all stated above whenever a change in one of the definitions occur and they don’t align anymore.

Why this helps

A signal when I need to take action and the reassurance that no news is good news make it so that I can confidently focus on feature creation. It reduces the mental load of constantly having to double check everything.

Dynamic check: from idea to work items

Now we have secured the product vision alignment with the strategic goals and the business case we can now dynamically validate ideas against it amongst other product definition artefacts. Every idea gets the same structured reflection, instead of gut feeling.

Besides a Product Vision I use the following product description artefacts:

• Jobs-to-be-done: defines the key user jobs, desired outcomes, and current frictions the product must address.
• Product charter: defines the principles, boundaries, and decision rules that keep the product aligned, focused, and consistent over time.
• Feedback: mostly anything users have mentioned regarding the product. If they really (dis)like features/behaviour it will be stated in this file.

The results of a new feature validation shows per subject (vision, jobs, feedback and charter) whether it aligns and if not what the conflicts are. Additionally if the alignment is below 4 there is a ‘what would make it a 5 of 5’ response.

The question for each item here is: how well does this idea align with our overall product description? And if not, why not and how can we make sure it does?

Why this helps

Quick feedback whether my new idea is aligned will the companies strategy and the product definition is priceless. It speeds up decision making without lowering the quality of those decisions.

Dynamic check: feature request from users

With this setup we now can validate and justify building/not building in a fraction of the time it normally takes. And do so with consistent reasoning. It saves the product team time. It gives clarity to the requester. So why not make it available for all stakeholders?

For now I would not automatically give the feedback to users yet but filter them myself. It is of course possible to fully automate this in the future.

Why this helps

Quick objective feedback to users if their request is something that will be build. Manages expectations and avoids endless discussions without clear arguments.

Just a little help

Creating great products is hard work. And since the development output increase, the demand for proper input is also increasing. We are getting faster at building, but not necessarily better at deciding what to build.

For ages we have been saying ‘crap in, crap out’, but we never really made sure the input was good enough. For the first time in years, I think we actually have a chance.