Agile Product Management for Non-Product Organisations: Benefits, Observations and Getting the Ball Rolling

Zeke Condon shares how non-product organisation can make sure their Agile efforts are successful.

This article was originally published here.

I have been working in tier-one corporations for all of my career. In my spare time, I have always been involved in startups, learning about new Agile delivery and ideation frameworks. As a product manager, I love agile principles – they allow me to organise my thoughts, focus on what's important, work closely with a team, learn and make mistakes and they encourage me to get out of the office and into the mind of the customer. It is clear from my experience and from looking at who the behemoth $Billion Startups that innovative and customer-centric products come from Agile product lead organisations.

So why are large, traditionally sales lead organisations having such a hard time to adopt Agile Product Management? I'll explore a few of the benefits of Agile product management, what my experience is in non-product organisations and some simple steps non-product organisations can take towards finally becoming product-focused.

An Agile Product team can deliver continuous value and less context switching if they are set up right.

Included in any Agile product organisation are a few key roles that are unmovable:

• The product owner/manager – The strategic thinker and the voice of the customer 
• The scrum master / delivery manager / project manager – The organiser of the group, team, task and metrics focused
• The delivery / core team – The doers, the ones who actually build/configure the solution 

These key roles are designed and defined in order to avoid cross-over of responsibilities and avoid context switching – sure, each one could probably do the job of the other (and will from time to time using their  T-Shape skills), but in order to keep chaos in order, the three need to be able to have both synergy and tension at the same time. By having all three separate, there is a natural tendency to challenge each other on what the role of the customer, the business and the employee is in every task, initiative and project, while focusing on their respective responsibilities: The product manager is working on research and strategic planning coupled with spurts of requirements/sorry writing; the scrum master / project manager is constantly engaging with the teams, keeping stakeholders up to date and playing the protector of the delivery team; the delivery team is focused on finding ways to solve problems, delivering on tasks and creating customer value. 

What non-product organisations are doing wrong: 

In my experience, non-product organisations dip their toes in and start with small product teams (one or two product managers), and all three of the key Agile roles get bundled together on their job description. When you put these three together into a single role (which I have seen a lot!), you create bias towards solutions that suit the individuals biased opinions; they deliver poor projects with large budgets and never on-time, and there is very little chance to talk to the customers amongst all the planning and doing. It’s a house of cards from there as the organization reacts and points the finger and says stuff like "we tried Agile, we tried product, it didn't work" - so back to old habits again.  

What can organisations do to get a product team right

An organisation needs to take a risk on investing in a fledgeling product team, but do it right. They need the right people to complete their roles, and they need to have the right tools in place to manage their workload. I find that the essentials are to give a product team at least one key player from each of the key roles, some accountability and some good tools. One of the firsts for me is to set up the front door (like Jira or other roadmap and project flow tools). This way, the product team manage their flow of info, stakeholders can see the progress of issues and the team can produce a process for capturing and validating ideas as they flow in.

Next up is to give product team awareness within the organisation. When I have joined new organizations and spoken to non-product colleagues (who have not been exposed to Agile it product frameworks), I am amazed by the number of innovative ideas for the product that come up (but are not captured). If instead you scale idea capture and allow the organisation to all be involved, you instantly give the product team an insights machine to start delivering value from. 

A well-formed Agile Product & Project management team helps manage scope creep & project risk 

All Agile frameworks encourage teams to fully define the problem before going to the solution. You are forced to break down the problem into its Epics (Problems to solve) and to decide (prioritise) which to do first based on which of the problems is larger (or has the biggest pay-off). Epics are then broken down further into smaller, deliverable chunks or stories that can be tackled in shorter amounts of time and start delivering each of the tasks until the list is depleted.  

This breaking down and delivering Epics and stories means that risk is minimised as is if the project should be cancelled or the direction changes, any Epics delivered will (should) already provide some benefits to the business. It also avoids scope creep (and the massive costs associated with re-establishing a baseline in a waterfall project) by allowing for change. If a new requirement arises, it can simply be prioritised and added to the backlog, and any smaller features that are less important are easily identified and bumped from the bottom of the list at the same time. 

What I find non-product organisations are doing wrong here

It is very easy to go straight from 'here is a problem' to 'here is a solution' and then start working towards a project that is to deliver functionality X. The issue soon arises that because the project was to focus on delivering functionality X, that widget Y is broadly related, so it gets added to the scope. Then you have new people added to the team, and they bring their amazing ideas and soon you have features XYZ. Before long, the scope has exceeded budgets and then there is a political battle to discuss what can then be descoped. Meanwhile, competitors and customers are moving on.

How can non-product organisations remove scope creep and risk today: 

I understand that it is hard to move straight from Waterfall to Agile, but the language used in Roadmaps and initiatives can help shape attitudes overtime. An example is the names and summaries of projects and initiatives should be focused on the problem to solve instead of the functionality to be delivered. First – clearly state what the problem is to solve (document it!!!) and then run the project under that statement (e.g. name your project 'Customer Experience Website project' instead of 'new website project'). That way, when there is scope creep, new people on-board or other distractions, everyone on the team will have a keen eye on the issue to be solved and should be able to prioritise a little easier. The added benefit is that changing this focus will make for an easier organisational shift towards Agile in the long run. 

Agile Product & Project Management creates focus by phasing product roadmap decisions:

Inherent in Agile frameworks, but not always called out, is the phasing of decisions and the certainty it gives to individuals working on projects. In Agile, you will always be certain that something is the right thing to do when you start working on it. This is because the task has been created based on a process of checks to get where it is. An example of this is in the use of user stories, personas and definition of done – if you don't have these things defined, you don't have a product to build. Being Agile forces you to define your customer upfront as a persona and that you know a lot about (through research about and interviews / taking with real customers). By having these personas, you have all agreed on what the target market/s are, what they want and what drives them. Then when you capture a user story (the traditional user-story style 'as a <person>, I want <feature>, so that <benefit>') you are forced to define the benefit to the persona. Then to close it out, you use an acceptance criteria and define exactly what you need to see before this is considered finished and to make sure that there is no ambiguity what so ever. 

What non-product organisations are doing wrong with roadmap phasing

For starters, non-product organisations do not break down their projects into smaller components and are not using personas, user stories & definition of done (or if they are, not wholeheartedly). This means that as the project starts rolling out, it is up to the team to keep reminding themselves of who they are building for, what benefits they are delivering – and the acceptance criteria is whatever the technical team say it is. There is general documentation in the project plan, but unless you are reading the project plan each and every day, I am sure the gremlins in your memory are going to take you astray and cause scope creep and delivery issues. 

From a roadmap perspective, in non-product organizations, I find that projects are either on – or they are not on. This is generally driven by the concept of funded or non-funded. Funded projects are a bulldozer, non-funded ones just gather dust. I have found that the effort that goes into putting together a business case to get one of these bulldozers, unfortunately, comes down to the will of a few people; and unfortunately as it is a hefty task, they can often be influenced more by what project will return for them and their personal needs (like getting towards a yearly KPI). This creates a business-before-customer bias, and everyone loses in that scenario in the end. It also creates a bottleneck for projects as only one project gets worked on at a time. 

What non-product organisations can do to phase their roadmap better

As a first phase, organisations should champion personas (and talking directly with customers). Personas should be encouraged across the organisation as a way to get in touch with the customers, ask them questions on a regular basis and get to know a bit about them. I find that each business unit will have their own take on personas as they will be in a different stage of the customer lifecycle (or BUs like operations may have personas for internal customers like the sales and marketing teams). 

Secondly, introduce project decision-phasing for when a project is to be presented on a roadmap. It will be a very hard task to move a non-product organisation straight into running projects with full Agile with personas, user stories and definitions of done when they have been delivering projects in a phased approach for so long. What is project decision-phasing? I found this methodology in the blog of a famous silicon valley startup a long while back (sorry, I cannot remember who it was for the life of me) and I have been using it ever since. It basically says that each project that is on the roadmap is in a certain state of decision. A project cannot go to the next phase until it has been signed off from the previous. This is a really good compliment to naming the project based on the problem it is trying to solve:

• Phase 0 – What is the problem we are solving? Is it worth solving? <ideation>
• Phase 1 – How are we going to solve that problem? <requirements definition>
• Phase 2 – What does our solution look like? <delivery>
• Phase 3 – How did the project go? (I added this step) <Post implementation review or project retrospective>

Full disclosure:

Please understand that these are my opinions and thoughts - and for the Agile and product purists out there, I have simplified some of the terminology that I find confuses new people to agile and product frameworks and this is not an exhaustive list by any means.

I have worked for 9+ years in product teams, and I still don't know all the answers, but very keen to hear your thoughts on the above. Connect with me on LinkedIn to share your feedback.

LinkedIn link: https://www.linkedin.com/in/zeke-condon/