Process for Prioritising the Product Backlog

I’ve spent the past year bringing a new product to market, as a consultant Head of Product for a start-up business unit that’s owned by a multi-national. I had the opportunity to pretty much start at the beginning: pulling together the vision, setting up a product council/steering group, talking to users about the initial concepts and shape the overall product direction.

After launching V1 of the product I ran a number of prioritisation meetings with key business stakeholders.

I’ve chaired and been involved in many different types of prioritisation meetings before. Somewhere there were up to 12 frustrated web editors (who managed sites where advertising was the major revenue stream) all had to bid for a slice of the scarce development resource. Prioritisation was done purely based on revenue: those sites whose demand for inventory was higher than what they were supplying won out.

Other prioritisation meetings comprised of me (the product manager) having to present and persuade senior stakeholders of the validity of a pre-prioritised backlog and drive consensus.

 Recently I decided to use the following process to not only prioritise the backlog but to aid in building unity among a group of stakeholders and win their confidence and trust:

  1. We agreed on the goal for the next quarter – in this case it was to build our user base as opposed to driving revenue. A hard sell for an ad funded business. 
  2. We went through the backlog and as a group agreed on the category of every item: User engagement, revenue, contractual, audience, acquisition etc... Most where no-brainers,  but the key was that the group felt that it had categorised the backlog. 
  3. By common consent a champion was assigned to represent each backlog item (represented in the meeting was: Heads of Marketing, Ad Operations, Head of Product, Tech Team Lead and the MD/General Manager of the business unit). 
  4. The champion would then give an elevator pitch on the importance of their backlog item followed by a brief Q&A cum discussion. 
  5. We would then vote (in the same way you play poker in scrum) on how the item would best fulfill the goal we all agreed on. Each score is then entered into the spread sheet. 
  6. When we get to the end of the backlog click ‘sort’ and hey presto we have a prioritised backlog.
Everyone embraces the outcome because: they participated, there was total transparency and we all bought into the goal for the coming quarter.

Finally I would present the prioritised backlog to the product council/steering group – in general it’s well accepted because either those present participated in its prioritisation or one of their subordinates was involved and reported back to them.

The quality of the prioritisation is directly related to the product manager’s ability to keep everyone on track, focused on the agreed goal as you vote on each backlog item.

Great Beta Programs — A Contrarian View

If your goal is great customer feedback during beta, people actually need to use it, and that means they need to sacrifice to make the time. And people only sacrifice if what is new excites them. A lousy beta product excites no one.

Respect that Knucklehead — 5 Daily Actions for Success

I judge every day in a binary way did we incrementally add to the value of the company or didnt we. I feel accomplished when we step forward and eager for the next day when we dont. I think this simple gut check makes life easier for a founder and keeps teams focused on what matters.

The Minimum Lovable Product

The MVP is a curse for ambitious technology companies that want to grow. You should be thinking about what it will take for customers to love you, not tolerate you.

What should keep a product manager awake?

Should it be the state of product development, the next release, the next sprint? Should it be what keeps the company executives awake? Should it be the competitors? While some of these should indeed keep a product manager awake, the most important thing that should keep him/her awake should be what keeps customers awake. Customers have problems today that are real pain points. They are struggling to solve them using current means and are hoping that someone will solve them. They are willing to pay someone to solve these problems for them. This is what product managers should focus on and spend most of their energies. If you do this, everything else should follow. If you do not do this, then all of the other things tend to happen – your execs tend to stay awake, you start worrying about competitors, your sales start to shrink, you start worrying about hitting the numbers etc. So focus on the only thing that really matters – understand better what keeps your customers awake and solve them via your products – existing or new.

Thoughts? Please share them via comments.

Power of “Breaking it down” – 10 minutes and NOW

It has been months since my last blog post. Call it laziness, lethargy, procrastination, sudden lack of confidence in my writing skills – every one of these had something to do with it. I used to tell myself that I had to do it. But never did it.

Last night, I was teaching my 9 nine year old daughter Navya how to compute the area of shapes. I was teaching her how to break the shape into rectangles and squares, calculate the area of each and then add them up. Suddenly, it dawned on me as to how I could break down this wall of not blogging.

Image

It is simple – “10 minutes” and “Now”. I even have this written down on my monitor at work. When something feels too big and I have trouble getting started, I try breaking it down into steps each of which would take 10 minutes. And then I start doing them NOW. Believe it or not, it has been working and a proof point is this blog post. I just opened WordPress and started writing.

Try it for yourself. Whether you are a software product manager procrastinating on starting a requirements doc for a complex feature or you are a painter wanting to start a painting, break it down into “10 minute” chunks and start on it “Now”.

10 minutes get over fast and before you realize you are 30 minutes into it. The sense of accomplishment suddenly carries you forward. Agile development methodology is built on this core principle of breaking things down, building fast and shipping often.

Do you agree? Thoughts, comments?

Image: Courtesy of digitalminimalism.com

Agile vs. Waterfall – what is the big deal?

I have been working in companies the last 5 years where we have followed the agile methodology in product development. Shorter sprints, faster releases as opposed to month long development cycles that were common in waterfall.

Here is a guest blog post written by Mike Cudemo of Sparta Systems that explains the differences between Agile and Waterfall product development methodologies in a very simple way. He also explains the benefits of doing agile as a way of increasing the success rate of IT projects.

Seeing is believing.  Agile methodologies are not perfect, but they are three times more successful than traditional waterfall methodologies (source: Standish Group).  Agile methodologies allow end users and stakeholders to visualize their requirements faster and catch errors earlier in the development process.

A waterfall process can be likened to building a house.  An architect translates your requirements into blueprints which only an architect can visualize.  Your first glimpse into reality occurs after the foundation is poured and the walls are erected.   While things can be changed, it is more expensive to change.  Most people struggle to catch problems until the drywall is up and the ductwork and plumbing are in place.  Again, you can make changes if there are issues, however, now it is even more expensive to address.  The waterfall process attempts to “freeze the requirements” after the blueprints are designed.   As you can imagine, this is not reality.  The later you catch a requirements problem (e.g. I want a larger master bedroom closet), the more expensive it is to fix.  In some cases, it is impossible to fix.  You can have the closet, but little Timmy needs to sleep on the roof!

The Agile Method does not attempt to “nail and freeze the requirements” all up front at one time.   It assumes that the requirements will evolve and change as the customer begins to visualize their own requirements.  The Agile Method attempts to build the house by first creating a visual 3D representation of the outside of the house.  This is how it is going to look when you come home from a long day at work.  After the outside look and feel is developed, you attempt to construct the house one to two rooms at a time.   The Agile Method attempts to focus the requirements, design, code and test into iterative smaller development phases.   Essentially, the Agile Method is a series of smaller contained waterfalls.  End users and business stakeholders get to see and experience the system as it unfolds.  Course corrections become more apparent and easier to navigate.

Waterfall processes attempt to minimize and control change.  Agile processes accept the inevitable need to accommodate learning about the real requirements.  End users think in broad strokes; however, we all know the devil truly lies in the details.   Skilled Agile development teams have a clear methodology to guide the process most effectively.  They will select the plot and then develop the look and feel of the outside of the house. Next, they will focus on the 1st floor, and then move to the second floor.  The finished basement will be last, because as we all know, we’ve run out of money by that time.

We find ourselves in the worst economy since the Great Depression.  Many CFOs find themselves in a complex juggling act of cutting operational costs and making technology investments.  CFOs are forcing their CIOs to come up with plans to leverage existing investments, yet develop the capabilities to rapidly respond to both economic growth and competitive changes. Project failure is really not an option, yet according to the statistics, waterfall approaches waste 60% of a company’s IT project budget.

Over 20 years ago, 90% of IT projects failed or under-delivered on functionality. Today, depending on your source for statistics, IT projects fail or under-deliver between 30-70% of the time.   It is better, but far from perfect.  It is clear, that Agile methodologies are at least 3x more likely to succeed.

Agile methodologies are iterative. Understanding is paramount to containing change.  Systems unfold one functional area and set of screens at a time.  An Agile Methodology will not fix a bad project vision, an impossible task, or a lack of skilled personnel.  Properly applied, an Agile approach will catch the poor vision, unattainable goals, or lack of resources early.  IT and application departments must learn that cancelling a project early is actually a win.   Broken processes should be fixed first before they become institutionalized with software or a system.

Companies that employ Agile methodologies and cancel unattainable projects early will thrive.  Their IT success rates will exceed 85%.  Most importantly, they will have more working capital to drive growth, innovate, and increase productivity.

About Mike Cudemo

Mike Cudemo runs the Customer Success Program at Sparta Systems.  The program accelerates knowledge transfer of best practices to our customers to enhance overall business performance.  Mike spent over 12 years integrating manufacturing operations with ERP and value chain systems at Fortune 100 clients, utilizing his expertise in value chain, quality, manufacturing execution and process automation systems. Trained as a systems engineer to analyze and simplify computer systems, Mike has spent a career helping clients understand their core business drivers, simplify the underlying processes, and automate the repetitive, non-value-added tasks which introduce defects and waste.