After a long phase without live events, we are super-excited to welcome you again to our next Product Leader Roundtable. It will take place on September 25th in Berlin. There is also an event planned in Munich on October 9th.
Together with Michael Frischkorn (CTO @PiNCAMP) Jörg Malang will be kicking-off interesting discussions with you.
“The new product must be delivered by November 30th at all cost” – who in product development has not already heard such demands by their stakeholders? Or: “You’ll have to work overtime when the deadline is coming closer!” is also popular. “Can IT estimate whether they can deliver Scope X until the end of the next quarter?” Nice is also: “We need a project plan so that we can manage the risks of the project better.”
How can Product Owners and development teams positively deal with such pressure? How can the following goals and questions effectively be addressed?:
Are we still “on track” or do we already have to communicate a deferred delivery of the next release?
How can we convey that the additional feature X will put the planned delivery date at serious risk?
How can we quickly develop a good feeling about the feasibility without defining and estimating the full scope in advance?
Developing products for customers is a highly complex endeavor. There are imponderables everywhere. Which features will be of the highest value for customers? Which requirements have to be implemented in which way? How long will the development of certain features take? These are questions that simply cannot be answered reliably in advance. There are many unknowns in the game, especially when you begin the journey with a team that has just been put together.
It is therefore all the more coherent that such projects are often approached iteratively, using empirical management. This lies at the very core of agile product development. It means that the work that must be done is not defined and planned at the beginning but rather that it develops over time. The idea is to work in small steps against a goal and to continuously incorporate newly gained knowledge along the way into the development process. This also enables reacting to unplanned events at virtually any time. However, this causes a problem for stakeholders, sponsors, and those in charge of the product development: it becomes difficult to predict delivery dates of product features, milestones, or even the entire product.
In the development of our e-commerce platform, we use so-called Burn-up Charts to continuously reflect upon our progress and to enable forecasting for our sponsors. We explain how we do this in the remainder of this text.
What is a Burn-up Chart?
If you have ever concerned yourself with agile methodologies such as Scrum, you might know burn-down charts. Teams use burn-down charts on a daily basis to record the amount of work they have been able to complete from the given scope in an iteration.
Figure 1: A typical sprint burn-down chart in Scrum
As shown in Figure 1, in a burn-down chart is visualized how progress is made in completing work from a given scope (red line). Ideally, the rate of completing work is near an ideal, linear line (grey line) that runs straight from the top left to the lower right. This can help the team to learn whether they are on track managing their work and how likely it is that they will deliver the planned scope.
This works well for tracking during an iteration because these are usually short and their scope is fixed. A typical iteration in Scrum – called a sprint – has a duration of one to four weeks. But what about forecasting for a whole product or a product release of which we neither know the exact scope nor the rate at which a team can deliver results of their work?
This is where burn-up charts come in handy: in principle, a burn-up chart is an upside-down burn-down chart in which the completed work is recorded. The resulting curve runs from bottom to top. The gradient of the curve reflects the rate at which work is being completed – the velocity. We use burn-up charts at the iteration-level, that is at the end of each iteration in the project, we record how much work has been completed. The actual trick, however, is to use a second curve that shows the complete known scope at the end of each sprint. Typically, the complete scope will be small at the beginning of a project and grow over time.
Figure 2: Burn-up chart for a product release
This is illustrated in Figure 2: the red curve, showing the work completed, runs towards the blue curve which shows the complete known scope at that point in time.
This way, we visualize well how completed work compares to the complete scope that is planned. Moreover, this enables us to forecast. A product release is done when the red curve intersects the blue curve.
Trend Lines for Forecasting
We plot trend lines at the earliest possible moment so that we can forecast when the curves might intersect. With every iteration we update all curves and trends, increasing their accuracy. The following assumptions are the basis for the trend lines: the velocity of the team(s) will increase slightly after the first few sprints and then stabilize at a certain rate. On average the red curve will therefore be a nearly straight line and it is fair to assume a linear trend for that curve if the team(s) remain stable.
Figure 3: Burn-up chart including trend lines for forecasting
For the blue curve, we use a logarithmic trend. This is based on the experience that the scope usually develops rapidly in the beginning before it becomes rather asymptotic. We often see that, in product development, little is known about the exact scope in the beginning. The amount of work that is believed to be necessary then usually grows quickly and stabilizes when more and more knowledge about required features is added to the product backlog. That is, the full scope of the product becomes clearer with time.
In our example in Figure 3, the full scope of the release is expected to be delivered in sprint 6. Room for maneuver results from either adjusting scope or from taking measures for increasing team velocity. However, as we know, the latter has smaller potential (“The Mythical Man-Month”, Frederick P. Brooks), and is in the short term nearly impossible.
What about Storypoints?
Alert readers may have picked up that the vertical axis in the burn-down chart (Figure 1) is captioned with “Story Points” while in the burn-down chart (Figures 2 – 4), we use the “Number of Issues”. Using story points is omnipresent in Scrum. Story points are an abstract measure, putting features and requirements (often User Stories) of different sizes into relation to one another. This relative estimation helps teams to better plan the amount of work they want to take into one sprint. Each team develops their individual scale of story points, which means that a story point has no meaning outside the team.
We do not use story points in our burn-up charts, instead, we work with the number of issues because:
Story points would be possibly more accurate but allow for what is known as Gaming (Goodhart’s law: “When a measure becomes a target, it ceases to be a good measure”);
With story points we would require an always completely estimated backlog so that we can draw the blue curve;
The imprecision is unproblematic to make a forecast. Greater precision does not add any new information.
That user stories differ in size does also not have a negative effect because what concerns us is the question: “Is there still work to do or not?”. The average size of the stories remains largely the same and is therefore not of any consequence.
By continuously visualizing the known full scope compared to the current work that has been completed, we uncover the main options to tweak in product management. This helps all involved to understand what is possible and under which conditions a release may be delivered at a specific date. Managing scope is by far the most effective activity if there is the need to deliver in sight of an approaching deadline.
Step by Step
In our development, we use several milestones. These are stage goals on our roadmap, each of them reflecting a certain subset of features of the product’s full feature set. They may be seen as early product versions. The scope of a milestone usually reaches a stable condition faster than the product’s full scope, allowing us to get a good impression early of when specific goals can be reached.
Clear Stakeholder Communication
All essential information is conveyed at a glance, including (sometimes) inconvenient truths. Arbitrarily, illusionary chosen deadlines will be quickly exposed as unrealistic. What’s possible will become apparent.
Gaming – Fudging improbable
Whether intentional or unintentional, teams will hardly be able to influence this kind of progress tracking in any way. So-called gaming becomes very unlikely. This is because additional stories would later have to be closed at some point. In other words: if additional stories would be used to pretend greater progress, they would be counted in the full scope as well. The distance between both curves would be the same.
Chopping stories into smaller (and thereby more) chunks would have the same effect. This would be compensated by the fact that then more stories would be completed per iteration.
Built-in Continuous Improvement
Indeed the forecast will be rather rough and imprecise at the beginning. However, after only a few iterations you will get a good understanding of what will and what will not be possible.
This helps to better get to know the teams and learn about the specifics of the entire ecosystem in which they operate, allowing conclusions concerning possible structural issues. The forecast will become more precise and more reliable with time.
Focus on the Essentials
The visualization focuses on the essential parameters, namely velocity, and scope. This clears the view and puts the action-guiding information right in your hands.
Using trend lines in combination with specific assumptions, which can be sketched in as data points, we can simulate and assess different scenarios. Every team will have to develop their individual strategies and solutions. For example, we have found it very useful in our project to assume a scope of approximately 600 stories towards the end of the project to visualize the converging scope, as shown in Figure 4. This enables us to keep track of a delivery date that we are approaching in about one year.
Figure 4: Burn-up chart with trend and assumption of future scope
This puts product owners in a better position when “negotiating” with stakeholders and sponsors, as the effects of feature creep on the delivery date can be highlighted well and clearly. For example, I sometimes make it clear as a product owner in such conversations that only 20 are “allowed”. This helps to manage expectations without an elaborate estimation process.
Finally, this approach allows us to even work with progress reporting in percentages in an agile project. The asymptotic curve reflecting the assumed scope tells us the expected amount of work without having defined all user stories or work packages in advance. This lets us elegantly derive the overall progress of the increment.
Our approach has immediately convinced our sponsors and executives when we first showed it to them. Another acknowledgment of the usefulness of this practice.
Dr. Timo Volkmer began his career as a consultant in computer science and information technology. He is an expert in agile product development, organization design, and works as a coach in these fields. Momentarily active at DER Touristik Online, he has previously worked as a freelance consultant for various corporations throughout Germany in agile transformations. Timo is dedicated to working with teams who create products that customers love.
Jörg Malanghas worked as a product manager since 2008, having held several positions as a chief product officer in enterprises of different sizes. Since 2018 he is a freelance consultant and owner of the “Senior Product Leadership Group (SPLSG)”. He advises enterprises in building effective and efficient product development processes. Jörg is dedicated to developing product strategies and loves agile, customer-centric product development. At the moment Jörg works on a freelance-basis for DER Touristik Online as product owner.
Our current CFO is an amazing human being, but he has still requested to operate from backstage. Someone I’ve known for over 3 years, currently employed at one of the large investment banks and is a certified financial analyst & fitness trainer. He also contributes to a set of family businesses and all of this keeps him pretty busy.
He seemed pretty enthused when I talked to him about the first project, however, a couple of weeks passed by and things didn’t progress (in regards to his confirmation of on-boarding). One fine day, after a gentle follow up, I received a call explaining the image above.
As is very evident, that list lists down a mental todo for the plans he had with his immediate and near term future. I humbly accepted but did strictly suggest that the part about not keeping clear communication with me wasn’t appreciated. I wouldn’t have expected such a behavior from him, at the very least after having been through something our friendship endured in the past year. I decided to give him a call and hang out while I got stuck at the Mumbai airport overnight.
I have a concept: “Be a river”, essentially suggests not to hold stuff in, never good for relationships (primarily the long-standing ones). Be polite, but feel free to convey how you feel, don’t hesitate to do so, if it’s not well received that wasn’t going to last or be fruitful for either person anyway.
Lastly, Product #2, Ghost Souls (ghostsouls.com), I shared the journey of inception and brought him in to help polish the commercials, now we have our CFO onboard.
Learning / Advice: People pursue a passion, readily commit to what excites them.
A hesitant CTO…
One that was open to being a sounding board, but wouldn’t sign an NDA or a contract. Our Current CTO, is someone with 20+ years of hardcore tech experience, is a bit of a geek if you ask me, could easily be a rocket scientist if he wanted, watches so many documentaries, not sure how he soaks & survives all that consistent stream of knowledge.
We’ve known each other for over six years, we’re more like brothers at this point, he’s kind to host and so I have a ritual of staying at his place anytime I visit Montreal, saves me money and also allows us time to catch up.
When I talked to him about Product#1, he did immediately and enthusiastically dove into the mode of exploring the idea, and readily shared his inputs and when offered the position of a CTO, verbally accepted.
Few weeks went by, while I was doing the groundwork, I reached out to him again to check-in and see when can I send in an NDA to discuss further and possibly sign a contract. We arranged a call, discussed the product roadmap at length, and established the baseline for competitor analysis, ending the call with an ask of sharing a contract and NDA template that has worked for him in the past (aka people used to sign him on).
And then began the era of follow-ups, one fine day I received a set of texts, you can see the texts received here:
And my responses here:
After a careful 90 minutes call, deep diving in all the issues he experienced with the three startups, and having subtly conveyed how my approach and thoughts are overtly different, we now finally have a rockstar CTO. The issues, he experienced, were lack of planning, misaligned expectations, and arrogant behavior from the last three founders he worked with, when we dove into my thinking and the history we carry, we were able to collectively clear the clouds that hindered this milestone.
Learning / Advice: When it comes to bringing amazing people on-board, be ready to have tough conversations dealing with past projection on current. If your intentions are in the right place, nothing can stop it from happening. The key is to always have a beginner’s mindset.
VP Business Development & Strategic Partnerships that denied to partner…
He was the first person I called when I made up my mind about registering my own company and starting work on Product#1, someone I’ve known for more than 3 years. Post the initial calls, he very enthusiastically followed up for further discussions and followed through with some proactive research, still love it, the best sign of the perfect person you want to absolutely have on your team.
Few days passed, we decided to talk about compensation, I offered directions to a few websites where startups typically list their jobs to look for some baseline and then come up with his expectations of what he feels would be the right figure. In the next two-three days, I received an email with a tailored cover letter and a business canvassing book (cost him a certain dollars on amazon). It detailed to the point different sets of responsibilities he had kindly offered to take on and to contribute to the verticals of Strategic & Financial Management. There was also an equity ask on the higher side and a little section that outlined his personal exit strategy.
What’s to be loved here? The preparedness, organization, thoroughness, thoughtfulness, and effort. However, I said NO, there were some red flags. You’ll find below my response elaborating and setting expectations:
Which led him to say no, very naturally. But the best part, here again, he insisted on catching up because he didn’t want our friendship to suffer. This tells you miles about one’s character. I was convinced immediately to drive this to collaboration but only after openly discussing the issues and ensuring there is an up-skilling of perspective on the other end.
We talked through all the issues, closed the gaps and we were successful in building that perspective and bringing him on-board with the same level enthusiasm he had initially.
Learning / Advice: Relationships matter always, commercials can always be worked out. Building credibility leads to stronger bonds.
Discovering a Rockstar CMO…
Took more than a few tries, cycled through six senior leaders in the industry, a few that said no because they weren’t comfortable growing revenue for a startup, including one that ghosted us, in the middle of a team meeting, which was supposed to be for discussing launch & growth strategy, even a few, with their own firms, only to meet our current CMO, during a networking call, with no intentions of going in there to find someone and recruit them. Currently, our CMO is helping us align our Brand Voice Unification, Brand, Launch, and Growth Strategy
Learning/Advice: It’s absolutely fine to spend time to find the right fit, the right person in the right role, really makes it worthwhile.
With that, I’d like to thank SPLSG to extend this opportunity for sharing these details. Should you have any questions/suggestions/advise or need inputs, feel free to reach me at:
Learn from peer Product Leaders about hot topics discussed in the community. Top speakers share their workplace experiences. Meet in an intimate setting (maximum 20-25 hand-picked participants) on March 7th, 2020 in Berlin. Looking forward to welcoming you there!
This is a question that is asked many times. And it should be answered on multiple levels:
How many product managers should be responsible for the output of a development team of size X?
How many product managers does your company of size Y need?
What type of product management organization is needed/possible for Z product managers?
There is a good article by Siraj Khalic about this topic: https://medium.com/atomico/europes-product-management-problem-9061bc71dc99. For the “Y” above, he writes about a status quo median ratio of 1:34 in Europe (aka if your company has 60 employees, you have a maximum of two product managers on average). For the “X” above, the number of 1:24 (aka if your company as a development team of 24, you have one (!) product manager on average).
If you take a look from another angle: Let’s assume you are working agile. Your individual squad size should not exceed six to eight. And this number (1:8) is confirmed by Siraj for the Valley, but not for Europe. I have experienced many cases where one product manager was responsible for two scrum teams. Sometimes supported by a “Requirements Manager” or a “Junior PO.”
Let’s finish this post by discussing “Z”. The size of your company is limited by the number of product managers you have and how you organize them – not the other way around. Let’s image you have a development team of 200. With the ratio 1:8, it would require 25 product managers. As one product lead cannot work directly with so many product managers, you need to establish a layer in between. E.g., you could have one Product Director with 3-4 Heads of Product reporting to him/her. This requires senior product leadership. If you don’t have this in place, the outcome of your 200 employee development team will be suboptimal.
I have been thinking about this a lot. We are all aware of the experiences and skills a Product Owner/Product Manager needs. But a Product Leader needs more than those “horizontal skills” to succeed in his or her organization. Here come the ones SPLSG believes are the most important:
Large Organization – A Product Leader needs to navigate in large structures. Typically matrix organizations and very senior stakeholders are something that requires personal experience.
Large Team – Managing 3-5 Product Managers is relatively easy. But what happens if you are responsible for larger teams? If there is a hierarchical layer between you and your (practitioner) Product Managers? Not to forget: The Engineering Team also becomes quite large. Very quickly a Product Leader needs to steer 50-100 Engineers. You will need a personal leadership experience of that size to succeed.
Business & Market Acumen – You need to have a commercial drive to customers and how go-to-market works. As a Product Leader, you cannot leave this to others. You need to actively contribute & challenge your peers and the CEO.
Strategy/(Business Model) Innovation – Building features and only looking a couple of months ahead will make your company fail sooner or later. You need to be able to conceive a future, describe it to your organization. You should have done this a couple of times already.
Stakeholder Management/Evangelization – Perhaps the most important one. You need to not only sell your product but also influence the decision making of your stakeholders. Beware the stakeholders of a Product Manager are not automatically the same as the Product Leader’s. You will need many years of stakeholder experience on a senior level to succeed.
Processes/Organization/Product Development – This is the “bread and butter” of a Product Leader. No shortcuts, no excuses. Organize & deliver – together with your Tech counterparts.
Agility/Entrepreneurship – Build-measure-learn is the mantra. But not only on practitioner level, but also on an organizational level. How to be agile/entrepreneurial in a context that is built for a predictable future? If you have never have seen this from inside out, you will have difficulties. But if you aren’t having this as a strong driver, you won’t be passionate enough to make it happen.
So, how many boxes do you tick as a Product Leader? Is there something important missing in this list? Please comment – We are looking forward to your thoughts!
Last Monday Luca Criscuolo and Jörg Malang (both SPLSG) welcomed eight product leaders to the second Product Leader Roundtable in Berlin. This time the topic was OKRs.
In this intimate setting, very honest and insightful discussions could happen. Applying the Chatham House Rule, it was possible to profit from peers without impacting confidentiality. Senior leaders from well-established companies, but also start-ups shared their business cases.
For me, the key takeaways were the following:
OKRs have three dimensions:
OKR definition (spend enough time and love into this and involve your organization)
OKR project implementation (think your project through in advance. Don’t take it lightheartedly)
OKRs as catalysator of a massive change process
Getting Top-Executive buy-in is crucial. It even boils down to how the CEO sees his/her role, the company values and the role of HR.
OKRs get Product Leaders excited.
Everyone in the group said in the final feedback round that they had profited from the day. The quality and intensity of the discussion and the hands-on relevancy of the presented business cases made their days.
We are looking forward to the next Roundtable. In case you are interested in being informed about our next event, please make sure to either become SPLSG member here or sign up for our public newsletter here.
In preparation of our Product Leader Roundtable in Berlin on 16/09/2019 focusing on OKRs, we are looking forward to understanding better how widespread this framework is. Please help us by voting below. Thank you!