The Contralto Board In Practice
The problem with most product management tools is that the focus is almost always focused on building. These tools treat product delivery as a "finish line". When you start describing things in terms of of a "sprint" or "velocity" that suggests that shipping is something to race towards. This approach wins in the short term for fast market movers but loses in the long term when the product needs to mature and scale.
It doesn't take long for the output to begin to look like slop when focusing only on the current and upcoming projects. Common characteristics of software build this way is a confusing user interface, slow performance and software that doesn't integrate with the reality that it's targeted users actually work in. At best the software is mediocre at worst it's incoherent.
The Contralto Board isn't another backlog or roadmap. It's a tool that assists a workflow where a product is continually tuned and grounded to reality so that it can deliver the best outcomes possible for its users. In effect, working with Contralto trains teams to become "outcome obsessed". Let's discuss the workflow that wraps around the usage of the Contralto Board and how you can start using it for your next features.
Defining the inputs and outputs for a Feature
We have a problem that needs to be solved. Before a single line of code is written, we define the inputs and outputs of our work.
Each new cycle starts with three questions:
- What problem are we solving?
- How do we define the setpoint (outcome) that we want to achieve once we are done working on the problem?
- How relevant is this problem right now (low, medium, high)?
These 3 elements form the specification phase of the Contralto Board. Notice that we are not yet talking about solutions. The point of this step is to fully understand the context.
At this stage:
- We gather evidence, not metrics
- We write short, factual Problem statements
- We set measurable Setpoints (desired conditions, not features)
- We assign Relevancy ratings to guide focus
This is where the ground truth is defined and is the basis for all work that follows.
Ideation
Once we have defined the inputs and outputs the engineering team can now use that structure to design and evaluate potential solutions.
During this phase ideas are rapidly sketched out using tools like wire frames or breadboards. The big idea is to keep ideas in a state where they can be rapidly iterated. This is the time to discuss edge cases and explore where things break. It's also a time to think big while also pulling those ideas back to earth after careful technical review.
Through this process several candidate solutions are arrived at with a cost. Some solutions are more costly than others. The product manager will review these solutions and assess their fitness to take the problem (input) and transform that into the output (desired outcome) for the project. Solutions can be combined or applied in an ensemble fashion. The important thing is that the inputs and outputs ultimately drive the product team towards the optimal solution.
On the contralto board this becomes the "intervention". Once everyone is satisfied it's time to begin building the intervention.
Building
The build phase is the most recognizable phase of this workflow. It's really no different than what your team currently does. You can manage the work with scrum, kanban or whatever else your team feels more comfortable with. The only difference is that with the contralto board you now have new "waypoints" to assist in steering the product towards the optimal state.
During building, the board functions more of a roadmap for planning the work but also continually validating that work. Regular demos and check ins can be scheduled to validate and tune what's being built and ensure that it still satisfies the setpoint. Relevancy could even change during building. If the relevancy drifts low then there is a real need to consider whether the feature should still be built.
Drifting away from the setpoint could mean a few things. Sometimes we learn far more about reality during the building phase. What seemed like certainty during planning might no longer feel so certain once we built something that is now concrete. It's important to reflect at these stages and understand where the intervention can be tweaked if it's not achieving the outcomes it was designed to achieve. In other cases it could be a misunderstanding from the developers about what really matters. They might miss the whole point or the epicenter of the feature while focusing on a challenging yet irrelevant aspect of the project. When these moments come up it's best to steer them towards what matters.
Post-Release and Realization Audits
Here's where the rubber hits the road. The "intervention" is now shipped and it's time to test if it meets the "setpoint". The setpoint should be attached to metrics that you can get data for and routinely update. The "realization" is the result of the intervention's ability to achieve the setpoint. All interventions start out with a realization score of "emerging" when there is little data to assess their impact.
But over time there will be enough signal to determine if the realization meets the following criteria:
- Achieved — Setpoint consistently met
- Drifted — outcomes weakening (if previously achieved)previously
- Failed — no meaningful change
- Retired — problem no longer relevant
In addition to realization it's also important to measure relevancy. A relevancy score is decoded with a simple "Low", "Medium", or "High" status. Anything that has moved to "Low" should be considered for deletion. Relevancy is a combination of "frequency" (how often the feature is used), "impact" (how strongly it affects user outcomes), "coupling" (how directly it ties with the setpoint), and "opportunity" (whether or not it creates a tangible gain for the business).
It's up to the product manager's bandwidth and preference to adjust the frequency of tracking realization. We encourage a regular but most importantly realistic cadence. It's better to be consistent than inconsistent. The important thing is that every feature in your product is evaluated this way continually. Overtime the product is steered towards maximizing outcomes and value. With the board you have a clear picture of what's working and what's not.
An Ongoing Control Loop to Perfection
The Contralto Board turns product work into an ongoing control loop. Keeping up with the contralto board is easy once you include the board as part of your toolset for managing projects. It's where all existing features are tracked and where new work is shaped and planned. Following it ensures that your product remains tuned to reality and that the end result is an intentional piece of software that delights your users.
In a future article we will look at some concrete examples of how this system fits into a real workflow and how Contralto will break down an exiof product into a Contralto Board.