Archive

Posts Tagged ‘scrum’

Design Thinking and Product Management

October 9, 2018 Leave a comment

I came across a great article on Interaction-design.org today.  What follows is a short excerpt from that article.  Follow this link to read the entire article.  It really is a must-read for anyone interested in Product Management, Lean or Agile.


Interaction-design_Design-Thinking

Design Thinking’s Phases

There are many variants of the Design Thinking process in use today, and they have from three to seven phases, stages, or modes. However, all variants of Design Thinking are very similar. All variants of Design Thinking embody the same principles, which were first described by Nobel Prize laureate Herbert Simon in The Sciences of the Artificial in 1969. Here, we will focus on the five-phase model proposed by the Hasso-Plattner Institute of Design at Stanford, which is also known as d.school. We’ve chosen d.school’s approach because they’re at the forefront of applying and teaching Design Thinking. The five phases of Design Thinking, according to d.school, are as follows:

  • Empathise – with your users
  • Define – your users’ needs, their problem, and your insights
  • Ideate – by challenging assumptions and creating ideas for innovative solutions
  • Prototype – to start creating solutions
  • Test – solutions

It is important to note that the five phases, stages, or modes are not always sequential. They do not have to follow any specific order and can often occur in parallel and repeat iteratively. Given that, you should not understand the phases as a hierarchal or step-by-step process. Instead, you should look at it as an overview of the modes or phases that contribute to an innovative project, rather than sequential steps.


Grand Old Man of User Experience, Don Norman, who also coined the very term User Experience, explains what Design Thinking is and what’s so special about it:

“…the more I pondered the nature of design and reflected on my recent encounters with engineers, business people and others who blindly solved the problems they thought they were facing without question or further study, I realized that these people could benefit from a good dose of design thinking. Designers have developed a number of techniques to avoid being captured by too facile a solution. They take the original problem as a suggestion, not as a final statement, then think broadly about what the real issues underlying this problem statement might really be (for example by using the “Five Whys” approach to get at root causes). Most important of all, is that the process is iterative and expansive. Designers resist the temptation to jump immediately to a solution to the stated problem. Instead, they first spend time determining what the basic, fundamental (root) issue is that needs to be addressed. They don’t try to search for a solution until they have determined the real problem, and even then, instead of solving that problem, they stop to consider a wide range of potential solutions. Only then will they finally converge upon their proposal. This process is called “Design Thinking.”

– Don Norman, Rethinking Design Thinking

outside the box

Read more…

Advertisements

Spotify Engineering Culture (Agile Enterprise Transition with Scrum and Kanban)

July 13, 2018 Leave a comment

Henrik Kniberg of Spotify put this video together back in 2014.  It describes the Podular Agile culture at Spotify.  It is both entertaining and informative, and I find myself going back to it every so often – as I did today.

Spotify+Engineering+Culture

You can find the video on YouTube here:  https://youtu.be/R2o-Xm3UVjs

Some highlights from the video:

  • Some concepts are more important than others:
    • Agile over Scrum
    • Principles over Practices
    • Servant over Master
    • Community over Structure
    • Enable over Serve
    • Trust over Control
    • People over everything else
  • Autonomous Squads
    • Be autonomous but don’t suboptimize
    • Alignment enables Autonomy
  • Fail-Friendly Environment
    • Fail faster than everyone else
    • Failure Recovery over Failure avoidance
  • Lean Startup Practices
    • Waste-repellent Culture
    • Impact over Velocify
    • Innovation over Predictability
    • Value Delivery over Plan Fulfilment
  • Experiment-Friendly Culture
    • Data-driven decisions
    • Chaos over Bureaucracy

Have a look and let me know what you think.  Does this sound like your Culture?  Was there anything here you took back to your team?

spotify-engineering-culture-part-2-agile-enterprise-transition-with-scrum-and-kanban-6960

 

Productization

Something that I think about every day is how to make sure the team is building the right thing.  Particularly in a customer-driven environment.

Image may be subject to copyright

Now, the answer may seem obvious – just build the thing the customer is asking for.  Well, the problem here is that the customer rarely knows exactly what they want, and more importantly, you don’t want to waste development cycles building something that your other customers don’t want.

 

Taking a Lean approach, we first need to define the problem space in the broadest possible sense, and define solutions.  We then need to verify these solutions against the customers who have the problem, and the use cases that are being addressed.  This means that we have to expand on the specific customer request and see how it applies to the larger product definition and to the larger customer base.

Productization.png

The diagram above simplifies this process:

  1. Starting with specific customer requests, define the Feature Enhancements that satisfy the request
  2. Define the problem space your are addressing, then expand that out to cover the broadest possible product footprint
  3. Define additional requirements that address the problem space beyond the original customer request
  4. Up-level all requirements into a General Product Specification (design spec, implementation plan, PRD – whatever your team uses)
  5. Prioritize the features and enhancements based on the specification
  6. Build and release (Go Live, GTM, Marketing, Sales, Support, etc)

Remember – the original feature requests from the customer may not necessarily be the top priorities.  After considering the broader set of requirements, prioritize the work and deliveries based on the value they add for the broadest set of customers.  It is tempting to only build what the customer asks for and then come back later and build additional enhancements.  But this wastes valuable resources and development cycles.

Always focus on delivering the maximum value to the broadest set of customers.  Make sure you understand when a customer has real needs, and when they are in “it never hurts to ask” mode.  Then, understand what similar customers need even though they may not have even asked.

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

 

 

 

The Three Levels of Prioritization. Or, how to eliminate scope creep and always deliver on time.

April 23, 2015 2 comments

tl;dr

The Three Levels of Prioritization:

  1. Must haves
  2. Nice to haves
  3. Wish we could have

——————————————-

I wrote some time ago about Themes in Scrum.  The focus of that blog post was to address the issue of lower priority items in the Sprint backlog.  The idea was to be purposeful in planning around potentially low priority topics such as help and tutorial pages, or documentation.  Click here if you are interested in reading.

Over the years I have learned much about prioritization – both as it applies to backlog grooming, and how it applies more generally. Proper prioritization is the key to keeping your sanity as a Product Manager. The magic of good prioritization:

  1. Forces stakeholders to think about what they truly need and what they can truly live without.
    – the problem isn’t identifying the top priority, it really is identifying priorities 2, 3, 4, and so on.  And most importantly, which items are the lowest priority – which items will not make the cut if push comes to shove.
  2. Sets expectations
    – everything can’t be top priority.  If we agree to work on the top priority items, that means we are not working on the lower ones. At least not right now.
  3. Manages scope and feature creep
    – when new priorities pop up – or stakeholder focus shifts – always ask the question “is this important enough to stop what we are doing now?”.  Or, “if we work on this, what can drop off the list of deliverables?”
  4. Always deliver on time
    – It’s virtually impossible to deliver both a promised set of features AND on a promised delivery date.  However, a hard delivery date can always be met if the feature set is flexible, and the feature set is always flexible in Agile – it is the Product Manager’s job to convince the Stakeholders of this.

How to always deliver on time

After you have forced your stakeholders to think about what they truly need and can truly live without, then managing scope creep and delivering on time are all a simple matter of proper prioritization.  .The first step is to construct a long-term, agile roadmap.   Remembering that in Agile, requirements and priorities can change sprint-to-sprint.  This does not mean you should avoid creating a long-term roadmap, it simply means that it must be constructed in such a way as to maximize flexibility and minimize wasted development cycles.  Use the following three steps to create a flexible, agile, roadmap:

  1. Identify the Minimum Deliverable Feature set
    – sometimes called the MVP – Minimal Viable Product.  If production where shut down unexpectedly, which features would allow the product to still be delivered in some form or another?
  2. Identify dependancies
    – which features provide basic functionality that can be built upon in future iterations, You do not want to start with standalone features that don’t support the broader functionality of the product.
  3. Prioritize the major features into 3 categories:
    • Must haves
    • Nice to haves
    • Wish we could have

While items 1 and 2 deserve attention (maybe in a future post), let us focus on item 3 – the 3 categories for prioritization. Must haves are features that the product can not live without.  These define our MVP.  Nice to haves are features that we would really love to build – features that add real value, maybe features that differentiate our product from the competition – but are not part of the MVP, and at the end of the day, we could deliver without.  Wish we could haves are the “wish list” items. Everybody agrees these features would be great, these features add pizazz and polish to the product, but expectations are low that these will ever be delivered.

The Wish we could have list is the most difficult one to create.  Some might be tempted to put fit-and-finish issues – the polish – into this category.  However, prioritization is dependent on the goals for the product.  Are you trying to simply get to market quickly with an MVP?  Or differentiate your product from the competition with attention to detail?  Apple, for example, would probably consider fit-and-finish as a Must have feature, whereas a start-up company with a brand new technology that just wants to get a foothold in the marketplace might define only basic functionality as the Must haves – fit-and-finish is on the wish list.

With this prioritization scheme in place, it is now easy (relatively) to commit to a delivery date. The commitment date will include all of the Must haves, as many of the Nice to haves as possible, and maybe some of the Wish to haves.  Always schedule time and resources around the Must haves and the Nice to haves. That way, the Must haves will always be delivered.  Unexpected roadblocks might result in some Nice to haves getting dropped, while any overestimations in time or resources allow some of the Wish we could haves to be delivered.

The 3 levels of prioritization as a fractal

To achieve the greatest level of success with this methodology, make sure you apply it to every level of the planning process.  Apply it to the MVP and the high-level roadmap.  Then apply it to the Epics within each major product feature, and again to each User Story within each Epic.  Finally, use the 3 levels in Sprint planning to fill each Sprint with Must have and Nice to have stories.  Time permitting, bring in extra Wish to have stories, or drop Nice to haves when things don’t go quite as planned.  As priorities change over the course of the project, you as the Product Manager can reshuffle what is being worked on without sacrificing the Must have features and stories, and will be able to articulate at any point in the project what is being worked on, what is being delivered, and why.

Autonomy, Mastery, and Purpose. Motivation and the Podular Organization, optimizing for innovation rather than efficiency.

March 27, 2014 Leave a comment

Today I would like to talk about a couple of principles and a couple of books that have had an enormous impact on the way I work.  The first is “Drive – The Surprising Truth About What Motivates Us” by Daniel H Pink, which is a brilliant look at how the “carrots and sticks” motivational techniques of the past are no longer valid and why we need to think about intrinsic – as opposed to extrinsic (external) – motivators.  The 3 pillars of motivation are:

  • Autonomy – the desire to direct our own lives.
  • Mastery – the urge to make progress and get better at something that matters.
  • Purpose – the yearning to do what we do in the service of something larger than ourselves.

The other book I want to talk about deals primarily with the last point – “Purpose”.  Once properly motivated, how do we get everyone in the organization to feel ownership of the business?  The solution is to create a “business within a business”. And this is the subject of “The Connected Company” by Dave Gray where we examine the concept of the podular organization and optimizing for innovation rather than efficiency.

These principles fit in nicely with the basic tenants of Agile – the idea of self-organizing and cross-functional teams.  As with other Agile processes, it seems (although it is not true) that these principles are much more applicable to smaller, leaner, more start-up like companies.  I have seen firsthand how Agile organizations fall back into old Waterfall traps as the organization grows, middle management grows along with it, and communication, motivation, and innovation become secondary to efficiency and predicability.  In a world that increasingly requires people to think creatively, solve problems and remain flexible in uncertain environments, hierarchical, multidivisional organizations and extrinsic motivation just don’t work.  The answer is to build flat organizations around small, self-governing “business within a business” units, or “pods”.

My experience applying these principle has primarily been with Software Develop teams.  While Software development seems particularly suited to these principles, it is left as an exercise for the reader to think about how they might be applied to other business’s such as hardware development, or service organizations.  

Organizing a large company into a series of “business within a business” pods, allows each pod to function as a stand-alone business unit, ideally only answering to its customers.  These customers may be inside or outside the organization, but each pod delivers its own business value thus giving its members real, motivational ownership of the pods success.  This is how a company optimizes for innovation over efficiency.

Within the pod, team members are motivated by the intrinsic value of the units success.  Developers, designers, sales, support – every member of the team must feel ownership of the teams success.  Autonomy and Mastery come into play as each member of the team is encouraged to identify and provide working solutions to the day-to-day challenges of creating success.  The parameters for success become clear, aligned with the goals of the larger business, thus empowering every member of the team.

“The great innovators in business did not succeed on creativity alone,” Gray writes, “their success was a blend of creative thinking and business logic.”

A great article on Fast Company sums it up nicely:

“So if you want to set a context to bring out your teams’ inner Edisons, you need to align their incentives in three ways:

  • Incentives need to breed visible impacts on the business as whole
  • Incentives need to balance short- and long-term thinking
  • Incentives need to reward people for doing what makes the business as a whole more successful and healthier

In this way, a person’s individual work is linked to the collective endeavor. They get personal expression and collective validation. They’re incented to do their best work, for themselves and for the organization.”

 

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.

%d bloggers like this: