POEM (Product Ownership Execution Model)

POEM (Product Ownership Execution Model)

POEM – its all about the journey….

The journey that starts when the seed (for an idea – to build a product or a service) is planted in the Product Owner’s mind. The journey that continues until that product or the services finally phases-out and is terminated. In no shape or form, this journey is a one-person act. In fact, it is all about a COMMUNAL EFFORT to take that idea from inception to a tangible product or a service and beyond, for consumption and reward.

The term POEM (Product Ownership Execution Model) is precisely coined here, as this model is designed to help and guide my fellow Product Owners to succeed in this so called journey. For an easy read and understanding, I have split the model into the following 7 steps.

So let’s dive straight into it…

STEP 1: The seed is implanted...

That very first meeting where the Product Owner hears for the very first time, the idea or the problem that the business is trying to solve, is when the seed is implanted in the his/her mind. This is a critical point, as this kick-starts the journey of taking this idea and evolving it to some tangible product or a service, and goes even beyond.

STEP 2: Establish Vision – Focus on the problem and means to measure the success

At this time, it is also critical for the Product Owner to focus on these 2 specific things:

First, try to clearly understand the business problem, without focusing too much on the possible solutions. Many times when the stakeholders approach the Product Owners, there is already a possible solution that is floating around. The discussion starts and revolves around a possible solution to some vague underlying problem. What Product Owners should do at this point is to gently keep nudging the conversation to stay within the guard-rails of the problem. This not only retains the conversation on the problem, but also helps unveiling the real underlying issues that needs to be resolved. Asking the right questions with the right people from different angles helps identify the real business. In several cases, further analysis is needed get to the bottom of the source of problem.

Also, understand the rewards and returns of successfully implementing the solution that would solve the business problem. This step is important, as it helps Product Owners establish metrics to measure the success of the implemented solution.

STEP 3: Identify the solution

Once there is a clear understanding of the business problem, it is time to analyze to discover possible

business solutions. I always suggest taking a 2 faceted approach when looking at the solution. One from the business perspective and the other from technical perspective. This is a good time to involve the technical experts – senior developers, architects and DBAs etc. to help with the technical perspective. When looking at the business side of the solutions, having discussions with stakeholders and other SMEs, in combination with analyzing related metrics and data is a good idea.

The outcome of the above exercise should be a solution that caters the business problem and is technically feasible.

STEP 4: POC and UI/UX review

It is a common; yet, not so good practice to immediately dive into coding user stories to start building the functionality at this point. I highly recommend using tools like balsamiq, mockUP etc., or plain old-fashioned whiteboard sessions to sketch out a simple process flow diagrams from application user’s perspective. And also, leverage some technical help to sketch out technical flow – indicating how the data and service calls will flow within the system.

Having a process flow comes in handy in having user interface and user experience sessions with the team. For the UI/UX sessions, it is always a good idea to involve a mixture of stakeholders, in-house UI/UX experts, some members from the development team to have walkthroughs and draw out screens. Thinking the process from end user’s perspective is key to user friendly designs. Since agile enforces an iterative approach, there will always be opportunities to improve the flow, which means not everything has to be locked-down before the work begins. As sprint demos and reviews occur, the designs will evolve.

Another key point to keep in mind at this time is to take an MVP (Minimal Viable Product) approach to focus on building and shipping-out a no-frills version of the product. The idea is to get something in the hands of your users (internal or external, depending upon the case) to be able to capture some feedback, as that gives an opportunity to learn and evolve. Remember, Rome was not built in a day. Products mature over time, and evolution based on feedback, is sustainable.

STEP 5: Usermapping exercise

This is a good time to have a round-up session with the entire development team to do an in-depth product planning session. Firstly, this gives the entire team an opportunity to understand what they are about to dive into. Secondly, making them part of this exercise, spreads out the ownership factor across the team. Lastly, no one else but the team is an ideal group of candidates to break down the work in smaller chunks.

In this meeting, the PO should give an overview of the original business problem, the expected returns and rewards to the organization on resolving the problem and business/technical solution to the problem.

The previously created process and technical flows, UI/UX designs should be brought to the table, to give the team a good understanding of the work to be done.

The entire group should then work together on a user story mapping exercise to break down the work into smaller chunks.

It is also important to identify and document any possible risks that could hinder the delivery of these chunks,

and come up with some mitigation plan to overcome these risks, in case they occur.

STEP 6: Start the cadence

Depending upon your setup – Scrum, Kanban or whatever flavor of Agile is in use, the development cycle starts. This is where you start building the product via your agile routine practices and ceremonies – sprint planning, mid-sprint backlog grooming, sprint reviews (demos), retrospectives etc.

STEP 7: And it does not end here…

It is a common mistake for Product Owners to shift their focus from a product, as soon as the release date is met and the product goes live. This is where the product starts its journey in hands of the end user.

It is critical, that Product Owners continue to retain their focus on the product keeping track of:

Post-release support for any issues.

Metrics on usage and outages.


Future evolution roadmap etc.

This information not only keeps you in-sync with how your product is performing in the market, but also feeds-back to you on how well, you performed as an owner of the product. Think of this, as an opportunity to learn and grow.

Really! Are you kidding me? How can I do all this and still be Agile?

Well, I will try and answer this question in advance…

The key behind this model is forward-thinking and better planning. As Product Owners, it is critical for us to juggle multiple balls, at a given time – no-matter whether you are a product or project based organization. At the end of the day, any effort of work can be managed as a project. No, I am not hinting to go waterfall. The key is that as the work for one project is in full swing and the development team is embedded in it, it is always good to initiate analysis work for the next project.

Hope this helps! Feedback is always welcome