One of the best tutorial videos on Product Management describes the Product Owner (or Business Service Owner) as the custodian of a funnel of work.
Work comes from stakeholders into what appears to be a large funnel, with plenty of expectations about delivery, which will be attended to by the engineering team. In reality the output of what can be achieved by the engineering team is mismatched with the input demanded by the stakeholders.
What can we call this funnel analogy to describe the pressures on engineering teams? The funnel of doom? The funnel of never-ending work? A name would be helpful. Comments at the bottom of the post please.
One part of the role of Product Owner is to prioritize work, discarding features that should not be worked on. Prioritization is crucial, because it allows constant alignment with business needs. Any other kind of queuing in a system with constraints, apart from constant reprioritization, is futile, otherwise you'll end up working on stale ideas that have lost their relevance.
How can Product Owners use ServiceNow to capture ideas and select the most valuable ones?
Determining the priority of ideas is sometimes more art than science. Work can be related to quality, improving user experiences that are blighted by bugs or usability issues, or new features can be introduced to address business opportunities or threats. Product Owners need a way of capturing Ideas from the business, rationalizing them, converting them into Demands which can then be prioritized correctly.
New in Eureka is a Demand Management application which helps organizations do exactly that.
In terms of DevOps or Software Development Lifecycle we're talking about the very start of the process. Inputting work to the value chain, which will be refined and worked on until the result is a newly deployed release into production.
After installing the demand management plugin a new item appears in the Service Catalog allowing business users to submit requests for improvements.
The form is provided in a minimalist state. Customers would want to improve it further by allowing some kind of taxonomy of ideas, to allow easy filtering of ideas by "Business Service" or "Scrum Product". Extending the record producer to include a taxonomy would allow automatic routing of the resulting Idea record which is derived from Task, and so can be manipulated by Assignment Rules or some lightweight business rule scripting.
Worth noting here that we are allowing any business user to append Idea records into the system. Whilst the old adage "The Customer is always right", we don't really want business users having access to our actual Product Backlog. Some evaluations about cost, value and risk (and other factors) need to be made before we treat the idea as something that might actually earn a place in the development teams sprint.
So the Idea table acts as a repository of requests that can be promoted by a Product Owner into a Demand record, which indicates that in someway the idea has been accepted and will get consideration.
The list of Idea records can be found under Self Service > Ideas and a recommended enhancement for customers is to determine some kind of service level, at least for the acceptance of the idea. Product Owners can never promise that all ideas will make it into production, but some guarantee should be made about response, and the Service Level Agreement application is useful here.
The Idea form is, again, in a minimalist state giving you an opportunity to decide how best to configure it.
At the stage where an idea has just been submitted the Product Owner will want to have a conversation with the submitter in order to make a decision about accepting or deferring the idea. Customers could easily use the more traditional Comments and Work Notes capability with the Activity Stream, or be more contemporary with Live Feed 2.0 on the form.
The resulting conversation should take the Product Owner to a decision point, hopefully agreeing that the idea is formed enough to go to the next stage in the Demand Workbench.
On clicking the Accept UI Action a new Demand record is created from the Idea and an association created between the two records.
Using the Demand Workbench to facilitate a stakeholder conversation
The Demand Workbench is a graphical interface that allows a Product Manager to hold a conversation about the relative priority of a demand. The problem with an engineering team that is servicing multiple products, multiple projects or multiple stakeholders is the conflicting view of priority. Typically stakeholders are incentivized to make progress on their own product or project, which influences the discussion about how best to use a shared engineering resource.
Have you ever been in a stakeholder meeting where whoever shouts loudest gets the results they wanted, whilst others don't get a fair allocation?
Using the Demand Workbench can't resolve political challenges but does give a focal point for stakeholders to discuss new Demands.
Note for those that are following along with the demo instance. The default state of the Demand Workbench is to show records in the Qualified state. A newly accepted idea results in a new Demand in the Draft state. You may need to remove the condition on the list to see your new demand on the workbench
Product owners can now evaluate Demands in a multi-dimensional way. By default Demands can be evaluated by Value, Risk and Size.
Although these attributes carry a numerical value which determines their position on the chart, and therefore whether the demand should be Considered, Re-evaluated or Resourced, by quadrant, I did mention that prioritization is sometimes more art than an exact science.
As such it is possible for a Product Owner to click and drag a demand to alter its position on the chart, shown in the animated GIF below
That's it for a quick introduction to accepting ideas from the business, rationalizing them and then discussing them with Stakeholders in a Product Owner meeting. The Demand Workbench goes on to allow you to create Projects from a demand to allow Project and Portfolio managers to track ongoing work.
1 Comment
