Archive

Posts Tagged ‘Product Backlog’

What is Product Management/Leadership?

September 20, 2017 Leave a comment

star_trek_classic_communicator_inhandI’ve said it before, and I’ll say it again: “Different isn’t always better, but Better is always different“.  Companies and organizations that fear change will cease to  move forward and cease to innovate.  And it is the job of Product Leadership to create, nurture and manage this change.

I have recently been out in the market looking for opportunities to advance my career.  I’ve been working in Product Management in one form or another, for nearly two decades.  In the course of interviewing for various positions, I often found myself trying to articulate what exactly Product Management was, and what value it had to offer – or more specifically, what value I had to offer.  I naturally assumed that leaders and managers in tech knew exactly what the Product department did.  I discovered that that was not necessarily true.  At all.

So, what is Product Management and how can great Product Leadership drive innovation and success in a company? Good Product Management is a sustainable competitive advantage. It provides process, structure, and focus for creating innovation and customer delight. Product Management helps Product-driven businesses create new markets, and Customer-driven businesses deliver customer delight. It is the job of Product Leadership to evangelize Agile processes, advocate for the customer, and drive not just User Experience, but Customer Experience.  It is said that process is the scaffolding of productivity.

Is there a difference between Product Management, Product Marketing, and Project Management?  Yes.  In startups and smaller companies, these disciplines are often all aggregated together.  However, at scale these are generally separate functions. In the broadest of terms,  Project Management is “how and when” a product is delivered.  Product Marketing tells the story of the product.  And Product Management is “what and why” the product exists in the first place.

“The job of a product manager is to discover a product that is valuable, usable, and feasible.” – Marty Cagan, Founding Partner of Silicon Valley Product Group

Product Managers are essential contributors at the intersection of business, technology, and user experience. In any company, Engineering will have ideas, Marketing will have ideas, the Business will have ideas, Marketing and Sales will have ideas.  People sometimes think that coming up with ideas is the most important part of the job.  In practice however, execution of an idea is much more important.  Product leadership isn’t just design or engineering or business or marketing. It is all of these things in a sandwich of stress and competing expectations.

“Product management is the glue that holds together all the various functions and roles across a company that speaks different languages.  It’s like the universal communicator in Star Trek – a hub of communication between all these different groups.” – Ken Norton, Product Partner at GV (formerly Google Ventures)

An important and unique distinction among Product Managers and Product Leaders is that they usually have no direct authority over the teams and processes they manage.  Transparency, communication, and trust are the tools of a Product Manager.  If you’re managing a team of creative people – developers in particular – you will be judged on how well you are able to protect them from distractions and what they are able to create. It is not about mindlessly barking orders at subordinates, but empathetically motivating creative personalities toward mutual goals.

“Traditional management is great if you want compliance, but if you want engagement, which is what we want in the workforce today as people are doing more complicated and sophisticated work, autonomy and self-direction just works better,” – Daniel Pink, author of Drive: The Surprising Truth About What Motivates Us (Riverhead).

Great Product leaders lead by influence and example. They need to be people-first communicators who can rally everyone behind a vision without much formal authority.  In his book Drive, and based on studies at MIT, Daniel Pink suggests that to motivate employees who work on anything above and beyond basic tasks, we need to focus on three factors:

  • Autonomy – Our desire to be self-directed.
  • Mastery – The urge to develop better skills.
  • Purpose – The desire to do something that has meaning and is important.

Product Management is often not about individual success, but about getting the best out of others.

On vision, prioritization, and planning:

Jeff Bezos, CEO and founder of Amazon –  “Be stubborn on vision, flexible on details.”

In order to set your team up for success as it scales, it’s important to consider what the core product and design principles for your organization are and articulate them clearly so everyone in the team understands them and can apply them in their work. As an example, Paul Adams, VP of Product at Intercom, uses the following three principles as the foundation on which everything they do is built.  I think these three principles are a useful starting point for any Product Management process.  Says Paul:

  • The first principle is that we think big but start small. This means thinking about a big vision and then ruthlessly cutting the scope so we can ship.
  • Because our next principle is ship to learn, which means shipping as fast as possible so we can learn as fast as possible.
  • The third principle is to design from first principles – to start with a blank sheet of paper instead of copying a competitor or assuming the best solution exists in the world already.

“Dream in years; plan in months; evaluate in weeks; ship daily.” – DJ Patil, Vice President of Product at RelateIQ, and former Chief Data Scientist of the United States Office of Science and Technology Policy.

Fail Fast.  For a Product Manager, deciding  whether to work on new problems or improve on existing ones is essentially an exercise in understanding what is most important to the customer.  Discovery is all about the effort you as Product Manager put into understanding your customer.  Great Product Leaders spend the majority of their time focusing on the discovery process.  And while talking to your customer about their needs is paramount, they can’t always give you the answers you need.  You oftentimes have to show them the solution before they even know they have a problem.  It is always a balancing act between discovery and delivery.  Discover for value then deliver on that value.  Prototypes, and the observations that go along with sharing them with users, are exceptionally powerful ways to gather this data.

“If a picture is worth a thousand words, a prototype is worth a thousand meetings.” – John Maeda, Global Head of Computational Design and Inclusion at Automattic

The Agile Manifesto:
To wrap up, I always like to be reminded of what Agile development is all about at it’s core.  The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


 

I was inspired by and borrowed liberally from the following books – which I highly recommend if you are interested in this topic and more:

“Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams”, Richard Banfield, Martin Eriksson, Nate Walkingshaw

“Inspired: How to Create Products Customers Love”, Mary Cagan

“Drive: The Surprising Truth About What Motivates Us”.  Daniel H Pink

“The Lean Startup: How Constant Innovation Creates Radically Successful Businesses”,  Eric Ries

And I am eagerly awaiting Eric Ries’s new book: “The Startup Way” . For more information visit thestartupway.com

 

 

 

Advertisements

What customers want

January 4, 2017 Leave a comment

Update: Just after writing this post, I started reading a great book – “The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers” by Ben Horowitz, and stumbled upon a quote that really articulates what I am trying to say with this post.  I decided to add the quote to the top of this post:

“It turns out that is exactly what product strategy is all about—figuring out the right product is the innovator’s job, not the customer’s job. The customer only knows what she thinks she wants based on her experience with the current product. The innovator can take into account everything that’s possible, but often must go against what she knows to be true. As a result, innovation requires a combination of knowledge, skill, and courage.”

What customers want.  Does it matter?  Depending on the kind of business you are trying to run, it may matter less than you think.

Is there a difference between a Customer-driven business and a Product-driven business?  After all, there is really only one goal – happy customers.  Right?  You either make things that people want, or make people want the things you make.  Business experts would postulate that there is a big difference.  And those differences are critical to how managers should run their business.

T0 the Customer-driven business, customer feedback is the cornerstone of success.  The entire product pipeline is based on information gathered on customers, and the focus is first and foremost on the customer. How to make the customer happy, how to meet or even exceed their expectations.  This type of business often operates under the assumption that it can only survive if the customers are satisfied.

In terms of marketing, the Customer-driven business is not greatly invested in marketing the product. After all, the product has been designed and created with the customer in mind, so it goes without saying that there is already a market (and customers) for it.

Speed and flexibility become the pillars of the Customer-driven business.  Unfortunately, in many cases the Customer-driven business is heavy on Sales, heavy on Marketing, and a little thin in Product and Technology.  Product Management is well poised to offer the benefits of process and discipline, but methodologies such as Agile and Lean are misunderstood and often shunned by Sales and Marketing heavy businesses. Without such discipline, products become ad-hoc and  meandering under the load of unending customer requirements.

The Product-driven business, on the other hand, cares much less about customer feedback.  Why?  The Product-driven business works under the assumption that with great products come great customers.  The Product-driven business exists to expand and create markets, create customers, and thereby create profits.  They are highly dependent on marketing since they make people want things rather than make things that people want.

In an existing Product-driven business, customer feedback at the aggregate level is crucial, but feedback at an individual level is almost irrelevant.  The Product-driven business is laser focused on the market they are trying to create.  Outliers most often point to customer-product mismatches.  Aggregate feedback should be used to validate the new market – not market fit.  Market fit implies that the target market already exists, which it does not.

Lean and Agile processes are essential to the Product-driven business because the new markets and customers are, in a manner of speaking, an educated guess.  The technology teams need to be flexible and fast as knowledge about the new market and new customers emerge.  MVP’s (minimal viable products) and validated learning cycles are the essential processes for the Product-driven business.  Sales teams need to be able to say “no” and move on quickly on the quest for the defined but unknown customer.  And Marketing is the portal through which these new customers will come.

One process internal, one  external.  Both require different approaches. Often times a hybrid approach results in an in-between process that serves neither.  Product Management needs to provide the leadership to help the company clarify the type of business, and then provide the tools and processes for success.

As a Product Manager, ask your self the following questions:

  • Is yours a Customer-driven business?  If yes, then
    • Customer feedback is crucial
    • Understand the role of Marketing.  If your business is truly Customer facing, then you should already know who and where your customers are.  Use marketing to build awareness, not to build a market.
    • Implement an Agile process for speed and flexibility.  Customer feedback should be coming in fast and furious, you will need resources and process to deal with it.
  • Is yours a Product-driven business?  If yes, then
    • Use customer feedback to support validated learning.  Focus on finding new customers and creating or expanding markets.
    • Rely heavily on Marketing to bring in the customers who need you, but probably don’t even know you exist
    • Implement an Agile process.
    • Create beta programs, identify evaluation customers, build MVP’s and Validated Learning loops

And remember attempts at hybrid models tend to die in an unlivable no-man’s land between product and customer-driven territories.

So yes, it matters what customers want.  But more importantly, know what you want from your customers.

Creativity comes from the darndest places

So we just finished our first sprint and the team is really energized.  Our velocity for this first sprint was 20 story points.  We used Fibonacci series planning poker to weigh user stories and decided to limit any user to 8 story points or less if it was to be included in the sprint. Anything greater than 8 had to go back into the backlog until it could be split up into smaller stories.  This left us with 5 stories, and a total of 20 points.  I am confident that our velocity will start to dramatically increase in a very short time.  We delivered all 5 stories, btw!

The grooming of the stories in this manner has revealed some interesting trends.  Since the user stories are fairly general, and only define “what” the software needs to do instead of “how” it does it, the development team has far fewer specifications on which to base their solutions.  At first, some team members where hesitant to move ahead without the details they were accustomed to in their past waterfall projects.  As Product Owner, I made sure the team knew that I trusted – and in fact was counting on – their creativity.  When a team member was not sure how I wanted a particular user story implemented, I would say something like “I don’t care how you do it.  Give me a couple of suggestions of how you would do it.”

It quickly became obvious that the developers were coming up with solutions that were far more clever than I or any Product Manager could have, and they were also taking into consideration far more of the long and short term ramifications of those solutions.  One of the devs said to me, “Man, the backend architecture is really going to require a lot of rework,” and then proceded to outline his solution and how he would implement it.  It was a very elagent solution.  “I hope we get this solved in time, some of the tasks in this sprint are dependent on it” he said.  To which I replied, “Even with your help, if I had gone off fully speced a backend solution myself, it would have taken me weeks.  And then I would have come back with a design for you to implement that probably wasn’t very flexible, and would have delayed the rest of the project.  By telling you what I needed instead of telling you what to do, you just solved the problem far more elegantly, and it’s only the 2nd day of the sprint!”

If  you trust the people who know the problem to solve the problem, the solutions start to flow like water.

Backlog Grooming

April 27, 2012 1 comment

I have been spending a lot of time this week – as you might imagine – grooming the ol’ Backlog.  I have been focusing on both the set of user stories for the upcoming sprint, as well as the longer term release schedule.  It is becoming increasingly important to look down the road and flesh out and prioritize the tasks and features we most need in our next release.  At our current sprint size of 2 weeks, we have a total of 12 sprints until we deliver the next public release.

Angela Druckman on the Scrum Alliance site, talks about backlog grooming:

Sometimes called StoryTime sessions, the purpose of these meetings is to make improvements to the Product Backlog.  That definition is deliberately vague because the meeting is quite versatile.  A Backlog Grooming session can be used to:
• Write user stories (it is possible to build a Product Backlog “from scratch” in a series of one or more StoryTime sessions)
• Break down user stories that are too big (epics)
• Improve user stories that are poorly written
• Estimate backlog items
• Add acceptance criteria
• Look deeper into the backlog to do longer-range technical planning

That last bullet is an important one.  Some people mistakenly believe that doing Scrum means never focusing on anything but what is coming up in the next sprint.  This is not true.  Instead, backlog grooming sessions are a great place for a Product Owner to say “The March release is coming along great, so today I would like to spend time looking at the user stories I hope to get in the July release.”  Doing this gives teams an opportunity to look further into the future of the product, and can alert them to technical challenges and “gotcha’s”.

For the entire article, click below:

How to Hold Effective Backlog Grooming Session

Themes in Scrum

April 18, 2012 1 comment

There is considerable discussion among Scrum practitioners on the subject of themes.  Sprints often have a theme, which is more akin to a goal.  User Stories are also quite often organized into themes to help with managing the overall progress of a project.  Id like to look at User Story themes a little more closely.

One issue that I foresee in our own evolving scrum process is that certain types of projects may not ever bubble their way up into a sprint.  For instance, features and UX may often seem to deliver the highest Business value, while refactoring and documentation may be viewed as important – even essential – yet never quite deliver the business value when compared to other more visible projects.  The situation reminds me of the old sports adage, “Second place is the first loser.”  The point here is, how do we make sure that our sprints address a wide range of topics, and don’t get overly focused on only the highest priority items?

As an example, an epic user story describing a rich product feature that delivers a great deal of tangible business value is decomposed into perhaps a dozen smaller user stories of decreasing business value.  The highest value stories are the ones that deliver the minimal marketable, or minimal usable feature set, and their associated validation processes.  Next in line might be features that are essential to a finished and professional product, followed by “nice to have” features.  Finally, if we are smart enough, we have added stories for documentation and help, sales support, or even training.

So, what happens when we complete a sprint or two and deliver the highest value subset of stories and now start planning the next sprint?  Well, there is a very good chance that other high value features are in the backlog that trump the remaining stories in our first feature set.  Now, our goal may very well be to deliver as may minimally viable features as we can, which is a fine goal.  However, were does this leave the “nice to have’s”?  The documentation and sales support?  It would be nice if we could prioritize these before we forget everything that went into building the higher value stories.

I think the solution is to create themes for the user stories and commit to adding stories from all themes into sprints as appropriate. For example, maybe documentation and help is only 25% as valuable as the major features of the product.  Now, we clearly don’t want to neglect the high value features, after all, customers don’t buy a product because it has good help screens.  However, customers do stay with a product and tell their peers about it when it is polished and the user experience is great – so we don’t want to neglect these features either.

What I propose is that the Product Owner commit to organizing the backlog into Themes that allow some of the lower relative value items to be addressed on a periodic basis.  For instance, in our example above, we determined that documentation and help generally had business values around 25% of that of the highest value feature stories.  Then the team should commit to addressing stories in this “theme” once every four sprints.  In other words, the goal of every 4th sprint should be to focus on documentation and help themed stories.  That way, the highest value items always get the highest amount of attention, but 2nd, 3rd, and 4th place see a little action, too.

Here are some suggested themes that I think might work for our specific sprints:

  • Major user functionality
  • User experience (UX)
  • “Nice to have” features and product polish
  • API’s
  • Documentation and Help
  • Training and Sales support
  • Marketing support
  • Back end architecture and Data Modeling
  • Refactoring

This list is very much off the top of my head, but I am sure it could be fine tuned.

The Power of Small Batches in Software Development

April 3, 2012 Leave a comment

As our company moves forward with implementing Scrum, it’s good I think, to review what it is we are trying to fix, and what it is we are hoping to accomplish. Our legacy processes have been plagued with classic waterfall problems.

  1.  Long release cycles
  2. Massive, often difficult to manage, complexity to the product.  Features are difficult to test and document.
  3. Development resources are “Interruptable”.
  4. Progress is often measured by “Vanity Metrics”
  5. There is little flexibility or creativity once the process has started

Committing to 2 Scrum teams, and (initially) 2 week sprints has forced the team to begin an effort of breaking down the product, and the product features, into smaller and smaller pieces. Maintaining this list will be my primary responsibility as Scrum Product Owner. The advantages of breaking down the product onto digestible pieces is quickly becoming obvious;
The incremental releases will give us more opportunities to put working features in front of customers earlier and more often.

The smaller feature sets will be easier to test.

The team can better manage the amount of time team members spend on “firefighting” tasks such as support and operations.

As the team moves from sprint to sprint we will be able to judge and predict our capacity with considerably more accuracy – thereby cutting back considerably on over promising, or under delivering.

The team will have much flexibility to change coarse in response to feedback from customers and stakeholders.

The teams progress can be measured against real deliverables.

Welcome to Intelligent Product Design

April 2, 2012 Leave a comment

This should be an interesting  journey.  I find myself in the unique position of re-joining a development team on a product that I helped create nearly 10 years ago.  The product has come a long way since I left the original team about 5 years ago.  The original company has been acquired twice since I left and now enjoys some very substantial and significant corporate support.  This blog is intended to chronicle my experiences as the new Product Manager and Agile Scrum Product Owner.

The company is newly dedicated to Agile and Scrum, but my intentions are to also apply Lean methodologies and other related techniques such as Customer Development, Minimal Viable Product, and the Build-Measure-Learn cycle as described by Eric Ries, Steven Blank, and others.  Paraphrasing from “The Innovators Dilemma” by Clyton Christensen:

  • Corporations are very good at creating incremental improvements to existing products and serving existing customers – sustained innovation – but struggle to create breakthrough new products – disruptive innovation – that can create new sustainable sources of growth.

So, hopefully I can get some comments and  lively conversation here as we attempt to break the stereotypical corporate development cycle and inject some real Entrepreneurial spirit into this effort!

-Brad Reeves

%d bloggers like this: