From Industry the product conference 2019
In April 2019, I had the pleasure of attending the European edition of ‘Industry — the Product Conference’. This event was hugely informative and valuable for thinking about product management in enterprise organisations. It set off a further week of reflection and reading, which I’ve attempted to distill in to 10 key takeaways.
The organisation I work for, and which graciously sent me to the conference, has been around for ~25 years. It’s tremendous success in its corner of the online world, has allowed it to grow very large while constantly adapting. A few years ago, the company rolled out a product focused restructure. The goal was to foster ownership, break silos, and empower cross-functional agile teams to focus on the customers. This willingness to adopt modern methodologies is one of its strengths, but the change wasn’t easy, and upon honest reflection many have noted the new problems it has created. These 10 points are my attempt to make sense of what we got wrong, and what we need to know to continue our evolution. If you have experience with product management in enterprise organisations, perhaps you’ll find some value here. And, if i’m lucky you’ll share your thoughts and help me grow. ;-)
About the conference
The conference took place in the beautiful, vibrant, digital hub that is Dublin. It drew ~600 attendees from 30+ countries, and ran over 3 days. On the first day, attendees could choose from 1 of 2 half day workshops. One of these was presented by Dan Olsen — the author of The Lean Product Playbook, one of my favourite product books. The next 2 days, consisted of 15 speakers sharing their knowledge in 13 talks, 2 onstage interviews, and 7 talk shops (an alternative to Q&A, talk shops put 2 to 3 speakers on couches to answer and discuss questions from interested participants. I found this format led to some of the most valuable insights). In addition, attendees were treated to networking parties every evening, excellent food and drink at the venue and tons of freebies — my personal highlight being a book, which has become my new favorite product management title.
The 15 speakers were authors and industry veterans from many of the biggest name companies. The quality and calibre only stood out to me when the last speaker presented — in spite of being a famous Silicon Valley VC and former CPO of Tinder, I was not able to find much value in his contribution. But, what struck me about this, was how much I had learned from the 14 previous speakers.
10 Takeaways
1. Relevance
Often product management conferences and books tend to focus on building new hip mobile products for end users. The focus seems to be on innovation, end user customers, minimum viable products, prototyping, and A/B testing. They leave me excited but scratching my head about how, if at all, this applies to my role in our enterprise organisation. Refreshingly, this conference was different. Speakers directly addressed the reality that as product people we are often hired to work on established products. It is not all about “finding fit”, often it is about what to do next when relationship, motion and sometimes fatigue, are already a reality.
Furthermore, the speakers discussed B2B products and back end systems, and most of them came from an enterprise perspective.
The talk which most clearly demonstrated the relevance to me, was by Suzie Prince — Head of Product at ThoughtWorks. Her talk was entitled “Why continuous delivery is a product management superpower” and amounted to a summary of Accelerate — a book my organization has embraced.
To over simplify for the uninitiated, this book shares the findings of an academic study into the effect of DevOps practices (CI/CD) on IT organisations. It reveals the finding that companies which make effective use of these techniques outperform the competition and have happier staff.
Suzie makes the case that these practices allow for safe, predictable delivery, freeing us from the overhead of managing large, complex and risky delivery. This ultimately supports a focus on problem solving, which is the primary purpose of the Product Management role, and the major theme of the conference. More about that later, for now my takeaway is that good product management is on par with best IT practices and both are required for a software product organisation to be highly effective.
2. Formalizing
Product management as a career is newer than the organisational principles which it is based on. Until recently it would be perfectly normal to hear very different descriptions of the role, in articles and at conferences.
As the industry moved away from traditional approaches to building software, a void arose around managing of the product. Candidates from many different sides quickly flooded in to fill it. Modern startup founders are product managers by default. But, as the organisation grows and founders become CEOs, they must learn to offload much of the responsibility. Product managers of old were marketers, they knew how to prioritize the customer needs, but weren’t great at helping engineers and designers discover the underlying problem. Additionally they tended to be incentivized by sales, and could often drive product development against the long term interest of the product. Engineers got in on the action with the advent of agile, and suddenly new, well-marketed institutions were trumpeting the scrum product owner role. Their focus on rapid delivery and adaptability, however, said nothing about how to understand the problems or measure the outcomes, let alone validate what was being built against the business goals and capabilities. Companies like Apple and Ideo had a design led approach, trumpeting the needs of the user, and pushing back on agile to prioritize customers and discovery.
So it was little wonder that our product owner role, with its team lead legacy, was unique in the industry. That no longer seems to be the case — it was made clear that the product manager role is now formalized and that all of the speakers were talking about the same well-defined role. Furthermore, since it is new and the pool of experienced people is still relevantly small, the demand for the role is at a current high.
Moreover, there now appears to be a coherent product management career path and well-defined product management roles at multiple levels of the organisation.
Possibly the strongest indicator of this demand and formalization is the recent introduction of product management degrees — the University of Carnegie Melon now offer a Product Management MBA
3. Problem
The consistent theme of the conference was that product management should focus relentlessly on the Problem. This message was driven home repeatedly by each of the speakers, and epitomized by these, and many more, well known ideas.
“LOVE THE PROBLEM”
“AVOID THE FEATURE TREADMILLS”
“OUTCOMES OVER OUTPUT”
“SOLUTION POLLUTION”
“ESCAPING THE BUILD TRAP”
“SHIP TO LEARN”.
“INNOVATION IS SAYING ‘NO’ TO 1,000 THINGS.”- Steve Jobs
What this repeating theme drove home to me was that product management is not about delivery, managing engineers, or even coming up with clever solutions. It is about discovering understanding and obsessing about the problem — the beginning and all the way through. Ironically and refreshingly, it is not even about obsessing about the product. Like a hockey player that moves to where the puck is heading, instead of where it is — successful products are the outcome of focusing on the problem.
‘The Problem’ is not what business analysts spec out, it is not the new feature that marketers are selling, or the demands of the loudest customer. ‘The Problem’ is defined as the primary hurdle or opportunity that stands between the business goal and current reality.
Discovering the problem is the first step of product management, but the role is uniquely important in keeping the focus on the problem as solutions start evolving, and through the delivery process. When product people are responsible for delivery or excluded during the delivery, the outcome drifts away from the problem. I have personally witnessed this several times. Engineering’s focus on optimization and technology, coupled with the pressure of predefined dates and complex project plans, creates new incentives and steers the outcome away from the original problem. The result is the all-too-familiar relationship degradation. It starts with the customer being dissatisfied despite the spec being delivered and the project plans being followed to the date. This frequently spirals into blame, which gets bounced between the engineers, designers, planners, and even the customers.
Melissa Perri spoke of the Product Kata, a martial-arts like, disciplined approach of cycling past the same set of questions about the problem ritualistically at each step of the project. She describes how product management is about managing uncertainty, and the process of developing confidence.
Paul Adams — VP of Product at Intercom, says “Your solution is only as good as your understanding of the problem”. He told us that they’ve made “Starting with the Problem” one of their 3 core principles. Then he explained how they deliberately increased the amount of time spent focusing on the problem, relevant to time spent on design and building. Paul clarified that this is not to be confused with waterfall, it is an iterative process and the relevant percentages are reflective of the total time spent on each phase.
One reason that this way of working is difficult for organisations to adopt is, as Paul said, that “The visible output doesn’t reflect the work”. The fact is that weeks of focusing on the problem, can result in little more than a descriptive paragraph and corresponding confidence level, but the value is not to be underestimated.
As someone who loves to explore the problem with rapid prototypes and models, I was challenged by the idea that even prototyping is “solution mode” thinking. An obvious enough statement. But it reminded me that my own gut reaction is to jump into solution mode. It is the IT persons curse, experienced by engineers and designers alike.
So, as humble as it seems, focusing on the Problem is the primary purpose of the product manager in an organisation.
4. Roadmaps
Roadmaps are a contentious issue with product managers. More specifically, roadmaps as a list of deliverables and dates are a common bane, universally despised. With special expletives reserved for Gantt charts.
Therefore, many of the discussions were around understanding the pressures that cause business to request timelines, and pragmatic solutions to addressing the need while shifting expectations away from the old ways.
It is commonly understood that a project plan is a best guess presented as a fact, and results in the incentivizing of delivery over problem solving. The alternative is generally seen as a combination of projections over predetermined dates, and simplified 3 horizon planning — Current, Next, and Future. This usually goes hand in hand with strategic alignment through OKRs, and proper ownership free of dependencies.
I struggle to see how a company as deeply invested in the old ways of project management as ours can change. Product managers can shift the traditional expectation which business have for timelines by demonstrating through modern means that they are putting their effort in the correct place. But, when the managers of product people see their job as providing traditional project management timelines to their business leaders as I see here, then the solution is less clear. What this says to me, firstly, is that product managers should report into product managers all the way up to a CPO, not into project managers. Secondly, the organisation needs to understand the relationship between traditional project management and product management.
To be clear, the project plans and gantt charts which are currently being produced will continue to be needed as long as we have dependencies spanning silos and teams with different goals. More about that later.
5. Agile
Agile may have helped save the world from the tyranny of waterfall planning and gantt charts, but the popularity and commercialization of Agile presents new challenges and creates confusion around the role of product management.
Firstly, Agile (and its most popular flavours) are delivery focused. They have nothing to say about understanding the problem, discovering solutions or analyzing the outcome with respect to business goals. The constant tension between design and agile is a clear symptom of this.
While Agile is largely about helping developers adapt to change, in practice it has become about velocity. Without product management, companies tend to use scrum to deliver the feature that was decided upfront. Worst of all, thanks to huge popularity and a horde of for-profit training institutions, scrum’s product owner role has become the most popular understanding of product management. But, as many of the speakers pointed out, scrum’s product owner role is at best a small subset of the product managers responsibilities.
I’ve seen cases where so-called “product people” were hired as an interface between business, who determined what to build, and IT, who determined how to build it. In this case, the product people tended to play the role of project managers, but in a new agile world. They grew out of the Scrum PO role — writing stories, ordering them on the board, and communicating between IT and business. Unlike product managers, these Scrum PO roles did not take business goals as input and did not focus on solving problems. Instead, they played the very specific and limited role of the scrum PO, being kept busy by managing multiple Scrum boards. Then, as companies grew, they scaled these roles by introducing a product manager role, which was essentially a manager of Scrum POs. While these roles had more responsibility(and the product manager title), they were not what we refer to as product managers in practice. This is evident by the fact that they do not report to a CPO and are not given business goals as input. Something similar exists in SAFe, a scaled up version of scrum which is widely criticized for being a waterfall system wrapped in agile terminology. Marty Cagan, Author of INSPIRED: How to Create Tech Products Customers Love, discusses this in further detail on his blog.
6. Strategy
Strategy is about deciding how to decide. It’s not a list of deliverables, or even about deciding on high-level priorities. Too often, that is what I see happen in strategy conversations. Melissa Perri’s words were frighteningly familiar to me — “Most product strategies are wish lists of features.”. She quoted Stephen Bungay to describe what strategy is.
“…a deployable decision making framework, enabling action to achieve desired outcomes, constrained by current capabilities, coherently aligned to the existing context” — Stephen Bungay
I arrived home from the conference just as South Africans were heading to the polls for the National Elections. This brought me face to face with strategy in the real world. Most people are loathe to reveal their voting decisions, but everyone I spoke to was quick to tell me their strategy. Some would detail how they’d vote to undermine the party which they saw as the greatest threat. Others would support parties which were not their first choice, but which had the best chance of gaining support. I was impressed by how many people had different strategies for regional and national levels, and how these strategies tied into an overarching strategy.
In all cases, their primary goals were clear, and informed a strategy which itself was decoupled from both the goals and the decision.
By contrast, a few people would simply tell me who they’d vote for. Usually these same people couldn’t tell me why. Their goals, when pushed, seemed derived from those of the party they were voting for, and not the other way around.
Highly effective organisations achieve the seemingly impossible duality of empowering individuals to make decisions, while maintaining alignment. They achieve this through the correct use of strategy.
7. Alignment
Alignment is crucial, especially in large organisations.
Pooja Naidu told us about how dealing with EU General Data Protection Regulation (GDPR) helped the Financial Times overcome the alignment difficulties which they had been facing since scaling up. This large online media company mirrors ours in multiple ways in terms of industry and organisational structure, and shared lessons which are directly transferable.
The most relevant similarity is their siloed structure. Pooja tells how they struggled with the classic alignment issues before going into GDPR. Different silos made conflicting requests with equal urgency. Any work dependent on input from more than one silo was hampered by conflicting goals and required complex planning. When GDPR came along, suddenly all their silos had the same goal. This allowed them to create a shared strategy across the silos, which amounted to a massively efficient and successful project, unlike any before. This is the happy story of how the FT learnt the importance of shared goals and strategy. To quote Pooja:
“Don’t try to break down silos, instead bend and tailor them to your needs. There is no need to change program or line management. [If ]Everyone is going on the same journey and has to think about the execution of the strategy.” — Pooja Naidu
The key takeaway is that silos create conflicting priorities, which naturally lead to formal and informal coping mechanisms. The informal coping mechanisms are the rise of high leverage individuals. The innocent way this plays out is through frequent escalations, meaning that too often decision making is moved from individuals to senior management. But, by far the worst informal effect is rampant politics. Meanwhile, formal methods to cope with this take the form of chronic planning, complex commitment sheets, project plans and endless Gantt charts. It is heartening to know that alignment is possible, even in siloed organisations, and that, furthermore, a solution exists within shared goals and strategy.
8. Carving
The product is the whole thing that the customer interfaces with. Product managers should work as a team to manage the whole product.
I’ve learned that a common mistake companies make when becoming product orientated is to carve up the product. They separate it into parts and assign them to different product teams. Usually the intentions are honorable, aiming to promote ownership. This is what we’ve done, but ironically it undermines ownership by limiting the parts of the product that people can work on.
What we call “Products” I’ve learnt are more accurately referred to as “Features”. Different marketing tools are not different products, they are features. Even Accounts, Registration, and Payments are but different features of the whole product that our customers use. In our organisation, we haven’t only assigned these features to separate product teams, we’ve even split them across business silos.
So how do we scale product management? How do we create ownership, and support alignment across a large organisation? The answer I found at the conference came from exploring the surprisingly common use of the word “Project”. Initially I wondered if the term was being used interchangeably with product. But the answer seems to be that product managers and product teams form around projects to solve specific problems.
The key is that teams are not tied to products, or even features. A product manager who is part of a product management team which together are responsible for the whole product, will focus on a particular feature or problem. This starts a Project, which includes from the very beginning engineers and designers who join the product manager in understanding and solving the problem. The team may grow and shrink through the life of the project. Crucially, under the guidance of the product manager, the team remain focused on outcomes, as opposed to the output. This is achieved by the product managers relentlessly focusing the team on the problem, where traditional project management would have focused on timelines. Therefore deployments are not the end. Instead, they are seen as a way to measure progress towards a goal.
A final idea which the speakers helped me clarify, is that of the Cross Functional Team. I think this term is misleading, as it can be construed as a team of developers with different skills. Typically, we think of it as some front-end and back-end developers, with some QA people included. The point that was driven home by many of the speakers is that it should be a team representing a cross section of the business. Therefore, a team might be made up of members from sales, compliance, and two back-end developers who have experience with the different parts of the system (Accounts and Segmentation, for example).
Making product owners and teams indefinitely responsible for features or products is how we get ownership wrong. Product owners, whos’ jobs are tied to a specific ‘product’ or ‘feature’, are incentivized to obsess about that feature, instead of the problem. Therefore they cannot truly serve the business, and certainly not the customer. Engineers who own a particular part of the system become gate keepers, preventing the ownership and furthering the need for complex planning.
So, somewhat ironically in a product company, ownership should be on a project level.
9. Organization
A clear message from all the speakers was that becoming an effective product management business impacts the whole organization. It doesn’t have to destroy silos, but it does require vertical representation, lateral alignment, and perhaps some introspection.
It is not sufficient to just have some product managers. It is not a role to be filled in a scrum team, or to be confused as another level of people management. It is a crucial function in the organization which needs to be vertically incorporated. As with senior architects and the CTO, product management leadership is crucial, for growing talented product people. Furthermore, many of the speakers spoke of the vital importance of the CPO for advocating and representing product at the highest level.
Business verticals, likewise, do not have to be destroyed. Silos can be flexible as Pooja explained, but incentives must be created to align with the product. Rick Mironov recounted in great, and often amusing, detail the problems which arise from incentives that do not support the product. I appreciated how he displayed empathy for the segments of business which he had wrestled with. It’s not uncommon to attend a conference of a particular discipline, only to hear extensive complaints about the other disciplines. But Rick, as with most of the other speakers, was a pragmatic and dignified veteran. He spoke about Enterprise sales teams which are “Paid to subvert product plan”. Fortunately, we don’t have sales team problems (that I’m aware of) but, the point which Rick made clear is that “Conflicts about prioritization are inevitable”, and the “Differences [are] driven by incentives”. He was clear that it takes product representation on the most senior levels to balance and correct this.
The most fundamental question relating to us was captured in a Talk Shop session discussion where the pragmatic panelists made the seemingly obvious statement that Not all companies are product companies. It is entirely legitimate for a modern software company to be an IT services company. Another speaker defined the product as the thing which customers use to solve their problems. A simple statement, but worth considering in the opposite. When our customers want something new, do they simply use our APIs and products, or do they request new features from us?
10. Change
If there is one point of self criticism I’ve heard universally across our organisation, its that we roll-out new initiatives and reorganize too often, and too enthusiastically.
Most of the speakers discussed how to introduce principles and practices to companies. Universally, speakers spoke about not thrusting new initiatives onto an organisation, or carving the organization up in one massive re-org.
As with managing new products and features, the best practice is to select an appropriate initial customer or segment. Usually that is a small high-profile team. Have them implement the principles, structure, practices and processes. Remain focused on the problem, and expect the first attempt to miss the goal. Have the team reflect and perfect it for the company’s unique context. Crucially don’t allow other teams to get in on the action until its been understood in an isolated context. Then scale cautiously and deliberately. You shouldn’t need to thrust it on other teams, because as it becomes successful, other teams will want to work in that manner. Incidentally, this is also the recommended way of introducing OKRs to large companies.
Using VC investment principles inside traditional organisations is another interesting idea that stuck with me and which aligned with this incremental approach. It was primarily discussed with regard to new features. The assumption is that product managers need to convince business to invest in a particular feature. Those investments primarily take the form of engineering time, and the recommended approach is to ask for a limited investment for a fixed interval, after which business should reassess their confidence in the feature. Implementing initiatives such as OKRs or an updated product management structure, may benefit from a similar approach.
Large organizations have the resources to take risks which startups do not, yet large organisations become reluctant to change, and are frequently disrupted by newer companies and even the environments they create. Lets learn from product managers about how to effectively improve our organisations.
Closing thoughts
Focusing on the problem is by no means the only thing that product people do. I have not discussed here the myriad of other tasks and responsibilities they have. So, I hope i have not offended any product managers by over simplifying what they do. However, from a business perspective I think its important to understand what the primary purpose is. We know that engineers are hired to build software, which enables us to achieve our business goals. In the same way, it’s important to understand what role product people play. If the role is to interface between business and engineering, then we aren’t talking about product management. And, arguably the output will deviate from the goal.
I think one of the challenges we face is not a lack of senior buy-in, but maybe in a sense the opposite. My suspicion is that many business leaders, have reached their senior level, by not jumping into solution mode, but rather by successfully focusing on the problem. Therefore, I think these leaders implicitly expect this problem focus from all their people — the operational business people requesting work, and the engineers a like. It feels like a perfectly reasonable expectation, but without an explicit and empowered product vertical, I think it is very hard to realize in practice. It might be helpful to think of product management as a business role, which might be why Carnegie Mellon are offering an MBA.
Acknowledgements
My organization has been hugely supportive, and it is thanks to the effort and dedication of my colleagues, that I was able to attend this conference. I’d like to thank all the regular contributors, and the conference budget organizers in particular. I hope this article returns some of the investment that they have made in me.
The organizers of ‘Industry — the Product Conference’ also deserve a great thanks for running a superb conference. In particular, I’d like to give a shout out to Mike. He was super helpful at all hours, and was a life saver when I needed last minute help fixing an administration mess-up.
Mellissa Perri’s book was a perfect post conference resource, and has become one of my new favorites. After she described in eerie detail many of the challenges I’ve experienced, it became just a matter of how to get hold of her book. What a treat then, that it was given to us for free at the conference. There are many books which describe product management processes and techniques. But, her book is unique in explaining exactly what its like to be a product manager, and how the role fits into organisations.
Many of the quotes were taken from the slide decks, and official conference notes. Therefore, they might not have been spoken as such, but I believe they are credibly assigned. I’ve quoted selectively to make my points, but I honestly believe that the speakers would agree with my statements. That said, there is a lot more I have to learn, and would appreciate any corrections or conversation, that could grow my understanding.