2
EDITOR’S NOTE WHAT MAKES A GREAT PRODUCT MANAGER? Effective product management is as much a mindset as it is a skill set. Sure, strong technical, business and soft skills are essential and so is deep knowledge of the product, market, and customer. But what really differentiates great product managers from good is the mindset, one that involves the “why” frame of mind more than “what” and “how”. Having the right mindset enables you to do better with all your product management skills and knowledge. Starting with “why” is paramount. It has to do with having a strong conviction of why a product should be built to begin with. The answer to this why has to do with figuring out the real purpose of building and sustaining the product, not with any superficial answers. This is where you start with a clear view of the real customer problem or opportunity that is driving the need for a solution.You explore what is important from the customer’s standpoint. Once there’s clarity on this front, you should be able to crisply answer the question – Why would the customer intend to buy my product? Once you address “why” clearly, it triggers the most relevant “what” and “how” type of questions. For example, you take into account the success measures – what drives success for my product – how will I measure and track them? Your approach then is to think of the solution that’s in line with the real problem or opportunity that was identified.
– How will I price the product? – How will I go to the markets I have identified? For example, what distribution channels am I going to follow? – How will I deploy and support the product? Such a purpose-driven framework brings a lot of other ongoing side benefits. You are able to drive better prioritization of features by asking yourself – what really matters the most? You lean on doing “less but definitely better” versus “more and hopefully good”. The key point about the right mindset is to ask the right questions on an ongoing basis. Great product managers resist the temptation to be stuck in the traditional template models of product development. They use these models as effective tools only to the extent necessary but do not lose sight of the purpose-driven mindset.
Examples of other what and how questions that follow: – What will be my product deliverables?
Jitendra Golani
– What (which) markets am I going to go into?
Product Management Executive IoT, Cloud,Analytics, Networking Author | Prodmagazine.com
– How will I build the product?
3
5 TIPS FOR BUILDING EFFECTIVE PRODUCT MANAGEMENT TEAMS
Product management is at an interesting point. More and more companies embrace it as a way to supercharge the business, gratify customers and align the org, yet few product teams are able to deliver on these big expectations. I get asked by managers quite frequently how to get their PMs to deliver more, have more impact, be more accountable. The answer, more often than not, starts with management itself – its perception of what product management is, how it operates, and how it should be built in the
org. This post describes 5 of the most important ways to address this gap.
1. Focus the PM mission on value A good place to start is the definition of product management. Even here, there’s a lot of confusion.
4
PRODUCT MANAGEMENT
This is how I like to explain it.
The mission of product management is to find and help build the right product. What makes a product right? Two things: 1. It delivers high value to a sizeable market, and 2. It helps capture lots of value back. (Value can be monetary or other).
Deliver Value Org
Product
Market
Delivering and capturing value is obviously the job of the entire org. Finding the product that will best allow this is the responsibility of product managers. They don’t have to do it alone. In fact, it’s better if they pull in other people to help them. They don’t even necessarily have to have the title product manager – founders, CxOs, tech leads, and designers sometimes part-time-own product management (even if they don’t call it by this name). However, once you have product managers onboard you should hand them the difficult task of steering the product into the desirable but hard to get to high-value/high-value spot and keeping it there. That should be their full-time job. ***
Upcoming Workshop – Lean Product Management (Barcelona) Barcelona June 7–8 In this 2-day workshop, Jeff Gothelf (Sense & Respond, Lean UX) and myself will walk you through the principles and tools of lean product
management – how modern-day PMs drive business results and optimize for customer success. Earlybird tickets are available until April 1st. details here. ***
2. H ire product managers, not product owners In my early days in product management there were no product owners, just product managers. The term was introduced a few years later with Scrum, the most popular Agile development methodology. Product owner (PO) is an important role within scrum, working closely with the development team as the representative of the customers/users and of other stakeholders, and, among other things, managing a prioritized product backlog that feeds the team with work items. This sounds like a good fit for a PM, but of course it’s only a subset of what modern PMs do (more on this in the next section). In fact some believe that product managers shouldn’t even specify the solution, and instead frame the problem or opportunity and help the team discover how to best address them. This version of product management sits at odds with the more classically defined product owner. I’m not sure that the authors of Scrum intended to create a real-world role called product owner, but that’s just what happened.Today companies are hiring full-time product owners by the boatload, mainly for two reasons: • Recent interpretations of Scrum are putting far higher demands on POs, requiring them to write detailed epics and user stories, to attend planning sessions, retrospectives and daily standups, and more. This can easily become a full-time job. • Managers like the concept of dividing the work – strategic, outbound-facing product work handled by senior, full-fledged, product managers or by the managers themselves while the grueling tactical work is handed off to the POs. It’s not the first time this was attempted, but to my knowledge it has never really worked.
5
PRODUCT MANAGEMENT
If it’s not already clear, I’m not a fan of the current product-owner-as-a-full-time-job model. I don’t believe there’s a neat way to split product management work along strategic and tactical responsibilities and I don’t feel that’s a great work experience for the product owner. The solution lies in reducing the tactical load on POs, through delegation to team members and reduction in process overhead, enabling them to perform the other important functions of the PM. If you prefer to receive posts like these by email sign up to my newsletter.
3. E ncourage PMs to be intrapreneurs Google, Facebook, Amazon and other leading tech companies expect and encourage their PMs to act as intrapreneurs. They believe this is key to staying innovative and nimble. In this vein I coach product managers to employ both the mindset and the toolset of the entrepreneur even when working in larger companies. These include: • Optimizing for learning AND execution • Creating Agile plans that assume constant change • Setting and tracking metrics • Idea prioritization using impact, effort and evidence • Running experiments and build-measure-learn loops • Business-model focus I think it’s worth spending a few sentences on this last point because it’s major. According to Steve Blank, one of the originators of Lean Startup, the objective of a startup is not to build the best product, nor to drive the most short term sales, it’s to find a scalable and repeatable business model. I think there’s a lot established orgs can learn from this. The business model helps tie the two main parts of the org – the business teams (sales, marketing, business-dev etc.) and the delivery teams (engineering, design, QA, devops, etc.) into one organic entity – a sort of yin-yang of value delivery and capture.
Engineering UX DevOps Customer support Customer success
Sales Marketing Finance
Org
Delivery PM Business
Deliver Value Product & Business model
Capture Value
Modern-day PMs therefore no longer attempt to bridge between the teams or act as gatekeepers. They seek to break the walls entirely and get everyone to work together, with a focus on the business model as a whole. This manifests in crossfunctional-work, shared objectives, and user/ business-focused metrics, among other things.
4. L ook for the right skills, not for the right resume When hiring PMs there’s a usual laundry list of things everyone is looking for, however some qualities that are just important, tend to be overlooked: Analytical thinking – Good PMs are good at breaking problems into their parts, doing pro and con assessments, coming up with guesstimates, analyzing facts and data, and estimating probabilities and distributions. Interview question – “How much storage does Evernote require to support its UK users?” User/Customer empathy – The ability to understand and share the feelings of another person who may be very different from you is key to building a product that delivers value for that person. I found that some people are just more naturally inclined to see things through the eyes of their target audience and are able to articulate this view back to others. It’s not a common skill – most of us just assume that other people are like us. Interview question – “Design an AirBnB-like app for people who are vision-impaired”. Humility – Product managers have a lot of power over the product. An over-confident PM who fully trusts his/her intuition and judgment and does not need proof is every bit as bad as a manager who has these traits. Strong opinions, held lightly is what we’re after. Interview question – “Tell me of a time
6
PRODUCT MANAGEMENT
when you got into a strong disagreement with someone over the requirements you set. How did you handle the situation?” … and others get too much attention: Education – OK, I admit that I think that an engineering degree (or significant hands-on experience) is very helpful for PMs, but then again I’ve seen good PMs come from all walks of life. Background in psychology or design is a plus. Same for business degree.An MBA is definitely not a must. Domain expertise – I’m seeing companies spend quarters looking for a PM that has just the right experience in their industry and in their business model. Don’t worry about it – good PMs are generalists and can learn quickly. Don’t let go of someone talented just because of lack of domain knowledge. Work experience – It’s not hard to build an impressive-looking CV. Resumes are a way to filter candidates, but once the candidate is in the interview process, they should not play a factor in hiring. It’s the results of the interviews, ideally based on multiple interviewers, that should matter.
5. Set the right reporting chain Product managers are a special breed of animal – neither engineering nor business nor design. They thrive when they report to senior PMs who understand their unique set of challenges, can coach them, and give them the freedom they need to do their jobs. Reporting to non-PMs, while possible and not uncommon, can hamper career growth and performance.
My general recommendation to CEOs is to create a product org reporting to a chief product officer (CPO). If there’s no CPO its best to have the PM org report to a multidisciplinary manager that has responsibility over both product and business, typically the CEO or head of a business unit. It’s not a good idea to have product managers report to a pure-engineering manager or a puremarketing/sales manager. As well-meaning as those individuals may be, in both cases goals will not be well aligned. Instead of focusing on finding the right product the PMs may be asked to help close deals (aka business PMs) or help make engineers fully productive and happy (technical PM, or now, product owner). I’ve been there and I can tell you it’s not fun for the PM and not helpful for the org.
Final thoughts Product management has evolved a lot in the last 15–20 years. The methodologies and tools I teach PMs today are very different from the ones I practiced as a young PM in the early 2000s. How you build a product management team has changed as well. Finding the right people, placing them in a dedicated PM-orgs, and letting them act as valuefocused intrapreneurs instead of as (solely) product owners, will take you a very long way.
Itamar Gilad Product, Strategy and Growth Consultant Author | Prodmagazine.com
7
HOW DO YOU DESIGN A LARGE PRODUCT MANAGEMENT TEAM?
The first product managers were on their own. Now, more product managers are part of a #prodmgmt team. And in larger teams, in larger enterprises, we’re specializing. Imagine if you only had one hat to wear, able to focus on one of the product subdisciplines. What will product manager speciation produce?
8
PRODUCT MANAGEMENT
Who is on your Product Management Team? Many professionals and executives have a “team” that helps them be better at their job, usually outside where they work. For a product pro: • Deeper experts. Product managers are generalists.What we need to know is widening to cover more subjects while the spew of new knowledge in those fields is accelerating. Nobody can keep up with it all. So seek friends or consultants who can share their narrower and deeper expertise with you, answering questions or just briefing you on the latest in the psychology of persuasion over coffee. • Communication pros. You’re spending a godawful amount of time writing, in meetings, and presenting. You’ll want contractors to save you time and increase the quality of your talks, so Prezi pros to tune up your decks, illustrators to make your points, transcribers for meeting notes, copy editors to proof your words, media consultants to polish your press Q&A, a stylist to edit your pathetic wardrobe, speechwriters and joke writers to make your talks more effective, and someone to remind you to listen. • Product mentors. Others have been there, done that, before you. Learn how to be a good mentee to more experienced or insightful product people. Grab a mentee or two of your own and pay it forward. • Coaches. Great coaches help you master workplace basics, get your act together, and then build competencies and awareness you’ll use through your career.
Your product management team after speciation Most software product management involves relatively small ratios of developer-to-product manager, in the 5-to-1 to 20-to-1 range. What do you do when your product has hundreds or thousands of developers working on it, like big enterprise systems? Product management
becomes a function with many members and specializations emerge to make it work. Some emerging specialties: • Coordination. These are keepers of the feature lists. Just keeping track can be a full time job as scale grows. Add product portfolio management. • Roadmapping. Negotiating consensus around major milestones, themes, and releases requires political acumen and diplomatic skill. • User Researchers. The full time version of sneaking an hour to run A/B tests this week.Add statistical depth and more field investigation. • Agile customers. Writing user stories, accepting/rejecting work, and otherwise being the prodmgmt representative on this dev team. And that dev team. • Hospice. With 50 products in your portfolio, you’re likely retiring a product or a major release every week or two. Reapers will manage graceful exits for all the systems and stakeholders affected. • External relations. Some product categories (like health) have very strong outside stakeholders like government regulators, heavyweight customers, and press.This product manager is an ambassador to these outside stakeholders when they require attention in big doses. • Product Science. The team that leads product management process improvement. That measures how well the product management practices perform, making prodmgmt better. Advancing the art.
Phil Wolff GDPR Consultant | Reef9 Author | Prodmagazine.com
9
HOW BLENDING LEAN, AGILE, AND DESIGN THINKING WILL TRANSFORM YOUR TEAM
BUILDING A STRONGER WORKFLOW FOR DEVELOPERS, DESIGNERS, AND PRODUCT MANAGERS LEADS TO BETTER CROSS-TEAM COLLABORATION – AND BETTER PRODUCTS. The following is an adapted excerpt from Lean vs.Agile vs. Design Thinking by designer, team leader, and business coach, Jeff Gothelf. In 2016, I was preparing with clients for an upcoming training workshop focused on coaching a cross-functional team of designers, software engineers, product managers, and business stakeholders on integrating product discovery practices – a process to ensure products being created are both usable and useful – into their delivery cadences. During our conversation, my
client said to me, “Our tech teams are learning Agile. Our product teams are learning Lean, and our design teams are learning Design Thinking. Which one is right?” The client found the different disciplines at odds because these seemingly complementary practices forced each discipline into different cadences,
10
PRODUCT SUCCESS
with different practices and vocabularies targeting different measures of success. The engineering teams, using Agile, were focused on shipping bug-free code in regular release cycles (many teams call these “sprints”). Their ultimate goal was an increased velocity – the quantity of code they could ship in each sprint. Product managers, using Lean, were most interested in driving efficiency, quality, and reduction of waste through tactical backlog prioritization and grooming techniques. Not to be left out, the designers sought to bring the customer front and center by validating problem-solution fit with Design Thinking activities. Yet their activities, like up-front research and design exercises, were perceived as time-consuming, delaying the deployment of new code. Each discipline was working through its own ceremonies and tactics, targeting an ideal state of success unique to them. The collaboration, shared understanding, and increased productivity they were all promised was nowhere to be found.
“
Each discipline was working through its own ceremonies and tactics, targeting and ideal state of success unique to them. The collaboration, shared understanding, and increased productivity they were all promised was nowhere to be found.
“So what?” they asked. Each discipline should work in whatever way is best for them, right? No.Without clearly understanding the problem the teams are trying to solve for the business or customer, a core concept across Lean, Agile and Design Thinking, product managers optimized backlogs of work based on gut instinct and subjective preference from stakeholders. Without a clear understanding of the customer, especially key in Design Thinking,
engineers focused on simply shipping features – the more, the better – without a sense of whether they helped to solve a real customer need in an effective way. And without any sense of the feasibility or strategic alignment of their prescribed solutions, an aspect of Agile, designers came up with ideas that never stood a chance of seeing the light of day. With such differing practices, motivations, and measures of success, is it any wonder organizations find it difficult to reconcile these processes and create highly productive, creative, balanced teams? In my book, Lean vs. Agile vs. Design Thinking, I delve into all three of these popular practices and outline how they work, as there are valuable components of each. As an organization seeking to leverage the benefits of continuous improvement and a digital product offering, your job is to pick and choose the specific elements from each practice that work well for your teams and the brand values you’re trying to convey. I’ve found that a few core practices serve as effective starting points for cross-functional teams to integrate components of each discipline.You can learn more about these and other strategies in my book.
Work in short cycles. Assuming you know exactly how people will respond to change is the same as assuming you can predict the end state of a piece of software – impossible. Since you cannot predict how people will react to this change, making these assumptions is highly risky. To reduce the risk of implementing sweeping process changes that fail, take small steps, a key component of Agile and Lean. Pick a new idea or practice and try it with a subset of your teams. Present this new practice as a “process experiment.” Let the team try it for a limited amount of time (e.g., two sprints) and see how it works. If it fails, the team has invested very little time and effort in this change, but (hopefully) they’ve learned a lot. If it succeeds, the team keeps the practice, improves on it, and the organization rolls it out to more teams.
11
PRODUCT SUCCESS
Hold regular retrospectives. Retrospectives are the heart of continuous improvement. Used frequently in Agile, they are a regular opportunity for the team to consider their current practice, evaluate its efficacy, and determine how to progress. Initial retros are uncomfortable and often feel like nothing more than venting sessions. Even teams who hold these sessions regularly often generate so much improvement material that it feels like very little is actually getting better. At the end of each sprint, encourage your teams to get together for an hour, review what worked well during that cycle, what didn’t go well, and commit to improving one or two key things each time. Oftentimes this will feel awkward at first but, after a few retrospectives, teams begin to open up more freely and address the core issues hurting their collaboration. If this fails to occur, offer teams an outside facilitator for these meetings. Someone without anything at stake in the retrospective will do a better job probing for root causes and solutions.
Work (and train) as one balanced team. The client quote that precipitated the writing of this book highlighted the discipline-based divisions at the root of that team’s dysfunction (and that of others). Part of the reason each discipline is training in a different methodology is because, while their vocabulary may have shifted, the way they work hasn’t. They continue to work in silos, handing off items from discipline to discipline.They are not working together on the same things at the same time. To combat this tendency, reconsider how you staff projects. The atomic unit of planning for any project is the team. The team is made up of designers, software engineers, and product managers at the very least. There is no “engineering team” or “design team” at the project level. These balanced teams provide the expertise, perspectives, and skill sets necessary for all aspects of a project.
12
PRODUCT SUCCESS
“
Balanced teams choose the best parts of Lean, Agile, and Design Thinking and apply them as needed in a tight collaboration.
learning from that, and then do the test again the next week. Don’t go offsite. Work in the office to ensure maximum participation. Most important, broadcast your findings broadly immediately after the test. Show the value of the exercise, reduce the commitment for participation, as well as the cost, and you’ll find an increased level of organizational buy-in for this classic product discovery technique.
When structured this way, it doesn’t make sense to train different members of the team in different ways. There is no difference in the cadence of engineering, design, nor product management on balanced teams. Their efforts have to be coordinated, aligned, and targeted at the same learning and delivery goals. Balanced teams choose the best parts of Lean, Agile, and Design Thinking and apply them as needed in a tight collaboration.
Do less research, more often. User research has been around a long time. As a tool in the arsenal of design teams, it was traditionally wielded with the subtlety of a giant hammer. Regardless of what was being tested (or what the team needed to learn), it often required at least two days offsite, in a facility stocked with candy, a dozen test participants or more, and a broad array of team members checking in and out as their calendars dictated. With a competent moderator and reasonable testing script, almost every major issue was revealed within the first five test participants. Every subsequent one yielded little additional value and cemented the perception in almost every attendee’s mind that this was a colossal waste of time. The worst part? They were right. It was a waste of time. Now, don’t get me wrong. I am a huge advocate for user research. However, having been the victim of many of these sessions, I know how much waste is involved in each. In addition, I’ve witnessed firsthand how attendees, who were convinced that this was an essential use of their time, lost faith in the process and the technique. To avoid this, I recommend continuing to practice user research with a cross-functional team in attendance, but simply do less of it, more often. Instead of testing 12 people, test three. Take the
Prioritize product discovery delivery work equally.
and
One symptom that seems to manifest consistently across organizations is that the work that gets visualized is the work that gets done. Agile, particularly, has very clear directions, ceremonies, and rituals around visualizing work. This is why, in most companies practicing some form of Agile, you’ll see physical boards or monitors displaying the teams’ work in JIRA or other digital project management tools. Agile advocates continuous learning. So does Lean Startup. Design Thinking focuses on learning as well. Yet, there is no clear process or ritual linked to visualizing learning work. The delivery aspects of Agile get visualized, measured, and executed. In this situation, Agile “wins” because the (valuable) activities of Lean Startup and Design Thinking rarely find their way into the same tools as the Agile activities. The result of this is that this work
13
PRODUCT SUCCESS
To avoid this, product discovery work must become a first-class citizen of the backlog. It must be visualized along with the delivery tasks. It must be prioritized against them and assigned to specific members of the team. It must be tracked like delivery tasks, and the implications of the discovery work have to be taken seriously. In many cases, learning will reveal gaps in your backlog or a poor prioritization decision. Changing your plans in reaction to these learnings is agility. It’s the whole reason to adopt this way of working and is the key to building responsive teams and organizations.
“
doesn’t get treated the same way as delivery work. It marginalizes the effort and allows it to be cut in the event of a time or scope crunch.Team members, often asked to meticulously track their time and effort on delivery tasks, are left to find time for discovery work “in the cracks” of their calendar.
Teams will optimize the work they’re incentivized to achieve. If you incentivized velocity, teams will work on getting more features out to market. If you incentivize learning, teams will build better product discovery processess.
only rewarded if user satisfaction reflects value in the features shipped. Incentives like these force the kind of self-organization Agile teams are famous for. Knowing that their company values these behaviors motivates teams to figure out which pieces of Agile, Lean, or Design Thinking will best help them achieve that. Jeff Gothelf is an author, speaker, and executive coach. He co-founded Neo Innovation in New York City and helped build it into one of the most recognized brands in modern product strategy, development, and design. He is the co-author of Sense and Respond (HBR Press), Lean UX (O’Reilly), and Lean vs. Agile vs. Design Thinking (S&R Press). Recently, Jeff co-founded Sense & Respond Press, a publishing house for modern, transformational business books. You can find him on Twitter at @jboogie.
Review your incentive structure (and performance management criteria). This is perhaps the most important criteria for ensuring your teams choose the most productive amalgamation of these philosophies to work with. Teams will optimize the work they’re incentivized to achieve. If you incentivize velocity, teams will work on getting more features out to market. If you incentivize learning, teams will build better product discovery processes. These same incentives must be reflected in your company’s performance management criteria. If you want to build collaboration and learning, employees must be assessed on the efficacy of their collaboration and their ability to build continuous learning into their work. For example, velocity is
Dive into Lean, Agile, Design Thinking, and more in General Assembly’s leading-edge workshops and courses. In our coding, design, and product managementprograms, you’ll learn strategies to improve workflow and collaboration between developers, designers, and product managers. For employers seeking to build and transform teams, GA offers assessment, training, and talent developmentsolutions for organizations of all sizes across the globe.
Jeff Gothelf Co-founder | Sense & Respond Press Author | Prodmagazine.com
14
Editorial Team JITENDRA GOLANI
Product Management Executive | IoT, Cloud, Analytics, Networking Author | Prodmagazine.com Jitendra Golani leads strategy and offer management for a global service practice focused on the Internet of Things (IoT) and emerging networking technologies in IBM. Jitendra’s background as services and product management executive has spanned driving creation and adoption of customerfocused solutions for IoT, Cloud, Analytics, and Networking technologies. He co-founded and championed Cisco’s network and data analytics portfolio.
ITAMAR GILAD
Product, Strategy and Growth Consultant Author | Prodmagazine.com Itamar is an experienced product and startup specialist, growth driver, and mentor, with more than 20 years in product and engineering in Google, Microsoft and startups. He helps tech companies in Europe build extraordinary products, vision, strategy, product market fit and growth, primarily using Lean Startup and Design Thinking concepts.
PHIL WOLFF
GDPR Consultant | Reef9 Author | Prodmagazine.com Phil Wolff specializes primarily in product management, project management, product retirement and other major pivots. He co-leads OpenOakland, and has run more than 100 mini-hackathons over two years, designing digital apps and engaging users to solve civic problems. Phil co-designed the City of Oakland’s first privacy and data retention policy for its metro video surveillance network.
JEFF GOTHELF
Co-founder | Sense & Respond Press Author | Prodmagazine.com Jeff is a consultant, coach, author and keynote speaker focusing on helping companies and organizations build innovative products, teams and cultures. He has helped teams implement crossfunctional collaboration, product strategy and experimentation and agile-friendly product design to maximize their success.
15
To contribute please write to – editor@prodmagazine.com Subscribe to magazine at www.prodmagazine.com Prodmagazine
@prodmagazine
Sponsored by
Prodmagazine