The Product Lead (PL) role has existed in our organisation for some time. On the face of it, the role is broadly comparable to the Product Owner (PO) role, as described by the Scrum agile methodology – some of the responsibilities match up.
The main difference is that the PO role is generally regarded as a full-time role working very closely with the delivery team, whereas our PLs are almost always individuals who have other full-time roles within their respective workstreams.
This poses problems, and creates frustration, as we have competing priorities for our PLs’ time. We could try to enforce the traditional PO role, but really it is for us as an organisation to define our roles, and what they do.
In an attempt to clarify the role, we wrote this guide for our Product Leads, around the things that we expect them to do –
Vision and Goal
You’ll be outlining the vision for the product or feature, and explaining the overall goal. Ideally this goal would be measurable. If you’re not sure what the overall goal is, try asking yourself ‘Why?’ until you reach the real value – see The 5 Whys
Detail
You’ll work with the delivery team to help define the features we’re going to build. We do this through User Stories and their Acceptance Criteria. The best way to do this is to provide us with specific examples – lots of them.
e.g. How should it behave when we do this? What should users be able to do in this scenario?
We have BAs to help with this, but you need to own the backlog of User Stories that will be built.
Value and ROI
You’ll need to justify your product, in order to obtain a project budget. Once we start working on your product or feature, you’re responsible for guiding the team to build the right thing, that delivers value and meets the goal you’ve defined. Any information you can provide on what impact or benefit the product has had once it’s been released is useful too.
Prioritise
As we’re working within a limited project budget, its important that we build things in the right order. We don’t want to use the budget up working on non-critical features. The best way to present priorities is a numbered list in priority order. You own the prioritisation, and you can decide what we should build next, as we learn more about what our users need.
Verification
We need you to get involved in verifying that we’ve built the right thing, as early as possible. The testing doesn’t all wait until the end any more. We can provide you with a link so that you can see your product growing in a test environment on a daily basis. The more closely involved you are with verifying the product, the better you will be able to prioritise future work, and shape the product.
Feedback
We love feedback! Especially from real users. It’s what enables us to build better products. The weekly review is a great opportunity to provide feedback on what is being built.
Meetings
We have a number of meetings during the development of your product. First of all you’ll need to work regularly with BAs, Architects and UX Designers in coming up with some early ideas and design work. Once the development and testing work kicks off we have daily stand-ups, weekly Reviews and Planning sessions, and Retrospectives where we look at how things are going. You need to be involved in as much of this as possible.
Team
Whilst your product is being designed and built, we’d like you to be part of the Delivery Team. We know you all have busy jobs to do, but the best deliveries happen when the Product Lead gets closely involved.
Proxy
You must represent other stakeholders in the business, including your Managers. Make sure you manage their expectations, and let them know about any decisions that are being made, as early as possible. You are the main line of communication between stakeholders and the team delivering the product.
Documentation
You’ll need to update the documentation for your product in our Product Wikis. This involves creating and updating wiki pages so that the relevant people across the organisation understand, and can support, your new product or feature.
Joe Blogs 