In today’s world we are constantly confronted with the message that the competition is breeding down our necks, that the market and environment are changing and we need to change with them. And most importantly, we are told that we need to listen to our customers to be able to provide the right products. We as a Product Managers need to be able to see beyond the basic product decisions, e.g. do we add feature A or feature B? We need to think beyond the silo of our function to be able to drive innovation into our products. In this session we will look at the role of Product Managers in an agile product development environment, and as agents of innovation
14. Slow Processes: a (BAD) example
Time
Added Value
One day
Brainstorming
new product idea
6 months trying
to get the project
approved
6 months product
development
15. Consequences of slow processes:
• Higher costs -> due to the amount of
work that is pending while the costs are
accruing
• Lower quality -> slow processes allow for
“dirty” workarounds and hide quality
problems (which in turn increase costs
due to rework)
16. Corollary of fast processes
For any given process, if
you can reduce the Time it
takes to execute it, you will
consequently reduce Costs
and increase Quality
17. CASE I: How to reduce the time it takes
to execute a particular process
Give me your business card or
Send me an email: vasco.duarte@oikosofy.com
To get this case study
23. Different content abstractions for
different stakeholders
Epics
Features
User Stories
Portfolio Items
– Customer
marketable
Longer term
planning (more
than 1 iteration)
Where the
rubber meets
the road – what
we do in one
iteration
Product
Marketing and
Portfolio
Product Owner
+ Architect + UX
Team +
Product
Owner
24. Different ways to manage a
portfolio of Epics/Features
Epic
Feature
Feature
Feature
Epic Epic
Feature
Feature
Feature
Feature
Feature
Feature
Epic
Feature
Feature
Feature
Epic Option 1:
Feature
Feature
Feature
• Many epics
• Shallow implementation
• New market / new business
innovation
• Typical goal: catch up (me too or
tick-in-box products for reviews) Epic
Feature
Feature
Feature
Epic
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Option 2:
• Few epics
• Deep implementation
• Technological innovation
• Typical goal: Hero products,
unique experiences, Niche-focused
products
29. CASE III: The learning process for the
whole company
30. Step 1: A classic waterfall-like process
framework
Product Realization General Availability Discontinuation
Development Release
Project
Initiation
DA Dn ...
S3 S1 V3 V2 V1 R1
S2 D1 R2
Idea
Screening
Release
Planning
Feasibilty
Study
System
Test
Beta
Validation
RC
Validation
Launch
Development Iterations Preparation
Market
Launch
Screening and Initiation Validation
D2
Product life-cycle and product realization cycle
• Learning comes too late
• Requires the world to be perfect
• Not flexible to changes (especially late changes)
31. Step 2: Agile process framework for the
whole company
• Includes feedback/learning cycles for major
company processes
• Regular reviews allow us to adapt to change
32. Now for the real challenge…
ACT III – How to take this into practice?
34. Flexible Scope techniques
Epic Epic Epic Epic Epic
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Depth of the portfolio
Is this Epic a “kick-ass” or a “me too”
or a “check in box”?
Breadth of the portfolio
How many experiences do we offer our customers?
37. Here’s a tip you can take to the bank:
Hire someone who has done it before.
38. Currently a Managing partner at Oikosofy, Vasco
Duarte is an experienced Agile Coach, Product and
Project Manager. Having worked in the software
industry since 1997, Vasco has also been an Agile
practitioner since 2004, he was one of the leaders
and catalysts of Agile methods and Agile culture
adoption at Avira and previously at Nokia and F-Secure.
Vasco's contributions to the development of the
Software industry and professions can be read at his
blog: http://SoftwareDevelopmentToday.com
Or you can follow Vasco on Twitter: @duarte_vasco
Tweet or send me an e-mail:
vasco.duarte@oikosofy.com
Editor's Notes
So we are here as Product managers. As people that want to contribute to one of the key aspects in our companies’ internal processes: doing the right things.
We can spend a long time talking about how we can do things better, but if we are doing the wrong things that amounts to being better at doing the wrong thing. Doing the wrong thing faster is not how we can be better than the competition.
In today’s world we are constantly confronted with the message that the competition is breeding down our necks; that the market and environment are changing and we need to change with them. And most importantly, we are told that we need to listen to our customers to be able to provide the right products.
You as a Product Manager need to be able to see beyond the basic product decisions, like do we add feature A or feature B. We need to think beyond the silo of our function.
You see, the problem is that we need:
To know what is next, so that we can be better than the competition
To understand what processes are slow, so that we can help make them faster and beat the competition to the market
To test what works so that we find the right product, the right product mix for our customers
All of these would be possible if we could learn and adapt quickly, including the customer feedback and faster processes. So, the question for us today is: how do we achieve that? How can we, as Product Managers, contribute to the improvement of our organization in a way that allows us to be better by learning and adapting to new circumstances; allows us to be quicker, by removing waste from our processes and do what is needed only.
Arguably we can be faster, much faster than we are today. When experts review the way we work in an average company they typically find that a large, very large percentage of the work that is done in those companies is just waste. This is work that we do (because we’ve always done those) but does not provide any value to our customers.
This is a serious issue because everything we do adds cost to our products or services. So, if we do not add value we are basically using money that we can never get back. No added value! Many consultancies quote value-to-waste ratios of about 1-5 %. That means 95% is waste!!!!
Another important finding is that slow processes are typically co-related with lower quality. This of course makes a lot of sense, because the quicker the process the less errors you can make. If you did the process would be slow, by for example: adding a large validation and verification phase at the end of the project (show picture of a waterfall with the testing/validation appearing at the end).
Waste can be removed from any process, but never by looking at that process in isolation.
Example of the manufacturing process: Value Stream Mapping and how-to
Waste identification and removal is one of the key tools in the Lean approach to continuous improvement. However being very good at removing waste can only make you faster. You still have to learn how to do the right things and give your customers a compelling experience or service.
One of the corner stones of Agile is Feedback, especially customer feedback.
Again, here Product Managers are in a key position to help their companies improve.
The first focus should be to stop working on long term roadmaps that are non-negotiable. Accept it, you cannot know now what will be relevant in 1, 2 or 3 years.
Fine, we accept it, but how can we make it work? How can I go to a customer meeting about a future product if I don’t have a roadmap?
These are important questions, but start by accepting that you just don’t know. When a customer asks you “What will I have for next year’s release/product/service?” you have an excellent opportunity to learn from that customer. Why not ask back “what do you see would be critical for your business in 1 year’s time?”
This builds a much needed dialogue with the customer and gives you a key advantage in sales: you just got your customer to partially commit to you by having them state what they want in your product!
So, the challenge is how do we manage the long-term development of our products without writing in stone the long-term roadmaps?
As a Product Manager you need to consider what is important for your business and have an idea of what your business should offer it’s customer, but tying your hands is not the best approach.
In one of the largest programs we’ve run we used a technique that allowed us to make our requirements flexible even as we gave quite clear direction to our development teams about the longer term (they need this for skill development for example). How did it work?
Three layers of requirements: Epics -> Features -> Stories with different layers of ownership and details.
These levels of abstraction allow the organization entities to focus on managing only the appropriate set of requirements that they need to get their job done.
The flexible portfolio with the 2 dimensions of flexibility
The example of the word-editor that can be Notepad or Word
The advantages of this approach is that it creates a feedback loop into the portfolio and allows us to manage the depth of each Epic to fit the time we have (innovation and competitiveness).
This is a technique you can start using tomorrow. Draw the two dimensions for your portfolio. Consider what is relevant for you: few deep features vs. many shallow features.
The case above is just an example of how you can create a feedback loop that helps your company learn and adapt to the reality as it emerges.
But there is more to Agile than Portfolio management. We need to be able to design processes that allow our company to learn and adapt.
In a waterfall project no one is in control at the end (show bug curve at the end).
Much overtime will be needed to get this product out, and that will be on your backs and on the backs of the product development group (be it software or other complex product). This typically leads to a pattern that some have called “Death March” (concentration camp picture), and that’s how it feels. It feels like we are marching to a concentration camp (rant about lives destroyed by this approach).
You have a responsibility to avoid this pattern in your place of work, and you can do it. Here’s how.
In an Agile product development process we involve the product development team from the beginning. This gives us a very quick feedback loop about the product we are designing and concepting. This feedback loop is important in order to
1. Create a product that is feasible from the technical point of view
2. Allow the R&D teams to contribute their deep-technical knowledge and provide technical innovation to the product that you may not be aware of. Example: take advantage of dual core technology
In one of the largest programs we’ve run we used a technique that allowed us to make our requirements flexible even as we gave quite clear direction to our development teams about the longer term (they need this for skill development for example). How did it work?
Here we can see a completely different approach to how to design a company-wide process. The overriding metaphor here is Cycles. Cycles that fulfill different needs in the company but that need to interact for us to be able to take advantage of the value created in each of the cycles. (Explain the function of each of the cycles and how that allows for quick feedback and learning)
So here’s what you can do tomorrow:
Analyze how you are working today and remove the work that is not needed. In GE they used to have workout sessions to do this. See: WORK OUT! You can use VSM as a technique and you can learn more here: (link to VSM example)
Work with your customers. Use the Flexible Content technique we talked about to both have a dialogue with the customer, but allow flexibility to include the most valuable knowledge that you find later in the project.
What cycles do you already have in your organization? Evaluate them and then use them to build a feedback chain. So that what you discover in the field is not lost, but goes into the product development process.
LINK TO WORKSHOP ON PRODUCT DESIGN (lean startup + design thinking)
Finally: stop adding new things before you get something out. Don’t fight mathematics, you’ll never win (Little’s Law). Stop starting and Start finishing!
Finally, I’d like to leave you with a tip that can potentially save you millions and millions of euros.
Hire someone with experience in this process!