svpg bloghttp://www.svproduct.com/articles/
Omni-Channel Producthttp://www.svproduct.com/omni-channel-product/
<p>Have you ever received a text notification from your airline about a flight delay before the ground crew in the waiting area has the information? Have you been unclear on whether to call your bank&rsquo;s web support or banking support line to answer a particular question? Are you baffled by the differences in your favorite retailer&rsquo;s in-store and online experiences? These are examples of omni-channel businesses whose products and services have a spectrum of customer touch points that span digital (apps, websites, notifications) and physical. In these cases, and many more like them, the company has not been able to unify the holistic customer experience.</p>
<p>Omni-channel products and services often provide value that is not digital. Many of these companies existed before the internet, some of them even before computers. Think of industries like banking, insurance, transportation, media, and retail. They established their core value, but the internet dramatically changed how they deliver that value to their customers.</p>
<p>These companies are often characterized by the presence of two distinct types of product managers: those responsible for the legacy product (e.g. actuarial insurance models, credit products, financial derivatives, academic data sets, etc), and those responsible for e-commerce and the digital experience. Actual role titles vary widely, but for the purposes of disambiguating the two types of PM in this article, I&rsquo;ll refer to the first group as &ldquo;Legacy PM&rdquo; and the second group as &ldquo;Digital PM&rdquo;.</p>
<p>Many companies maintain strong organizational and cultural separation between Legacy and Digital Product Management. Frequently, the two have little understanding of each other&rsquo;s job. In some cases, they don&rsquo;t talk at all.&nbsp;</p>
<p>This leads to fragmented user experiences like the examples above. What&rsquo;s worse is that the product organization can't innovate around a holistic view of the value they could bring to their customers. Consider an established auto insurance company developing a new &ldquo;pay per mile&rdquo; product where customers pay for insurance based on their actual car usage over any given period rather than a regular monthly period. Such a product requires intertwining the &ldquo;legacy&rdquo; value of new risk models and pricing, with &ldquo;digital&rdquo; value of gathering and displaying usage information. A company with strongly siloed Legacy and Digital PM will have a tough time discovering a successful product.</p>
<p>Of course, skill set considerations often motivate splitting into Legacy and Digital camps, e.g. Digital PM's in a credit card company can&rsquo;t be expected to have the same actuarial skills as the Legacy PM&rsquo;s. That said, these companies should find ways to promote a holistic view of the product in order to unify the customer&rsquo;s experience and innovate across the spectrum of value.</p>
<p>Here are some places to start:</p>
<p><span style="white-space: pre;"> </span>&bull;<span style="white-space: pre;"> </span>Ensure that Digital PM&rsquo;s have a deep understanding of the core business and the value that Legacy PM is creating for customers. Because of their role in creating the customer experience, Digital PM&rsquo;s are often driving product discovery. It&rsquo;s essential they know enough to generate new ideas, formulate hypotheses, and create experiments that integrate Legacy and Digital value.</p>
<p><span style="white-space: pre;"> </span>&bull;<span style="white-space: pre;"> </span>Embed Legacy PM&rsquo;s into cross-functional product teams. Here, a given Legacy PM is strongly associated with one or two product teams where they can closely collaborate with a Digital PM, designer, and engineers during discovery. Ideally the Legacy PM physically sits with the product team and contributes directly to product discovery work.</p>
<p><span style="white-space: pre;"> </span>&bull;<span style="white-space: pre;"> </span>Remember that product discovery is fundamentally about reducing risk; specifically risk around the value, usability, and feasibility of a product or idea. Regardless of whether the idea is based on Legacy, Digital, or a combination of the two, use discovery practices to gain insight and reduce risk.</p>
<p>Customers don&rsquo;t distinguish between the Legacy and Digital aspects of products. Companies that learn how to discover products that holistically blend these parts of their value proposition will be the ones that win.</p>
<p>&nbsp;</p>Tue, 06 Dec 2016 14:23:00 -0500http://www.svproduct.com/omni-channel-product/Planning Product Discoveryhttp://www.svproduct.com/planning-product-discovery/
<p class="p1"><span class="s1">Much of product discovery work doesn't actually require a lot of planning.&nbsp;We need to come up with a solution to a particular problem, and often this is straight forward, and we can proceed quickly to delivery work. &nbsp;But for certain efforts, this is decidedly not the case, and some planning and true problem solving becomes critically important. &nbsp;Big projects and especially initiatives (projects spanning multiple teams) are common examples.</span></p>
<p class="p1"><a href="http://www.svproduct.com/discovery-sprints/">Discovery Sprints</a>&nbsp;have some planning built into the start of the week, but we don&rsquo;t do discovery sprints that often as they&rsquo;re a special tool for an intense effort especially where we need to make a big decision in a short period of time.</p>
<p class="p1">For the other cases where some planning is called for but not with the time-boxed structure of a discovery sprint, I wanted to talk about how we frame our discovery work to ensure alignment and identify key risks.</p>
<p class="p1">There are really two goals here:&nbsp;</p>
<p class="p1">The first is to ensure the team is all on the same page in terms of clarity of purpose and alignment. &nbsp;In particular, we need to agree on the specific problem we are intending to solve (also referred to as &ldquo;job to be done&rdquo; if you prefer that nomenclature), which user or customers you&rsquo;re solving that problem for, and how will you know if you&rsquo;ve succeeded. &nbsp;Not accidentally, these should align directly to your <a href="http://www.svproduct.com/when-performance-is-measured-by-results/">OKR&rsquo;s</a>.</p>
<p class="p1">The second purpose is to identify the big risks that will need to be tackled during the discovery work. &nbsp;I find that most teams tend to gravitate towards a particular type of risk that they might be most comfortable with. &nbsp;Two common examples I find is that a team will immediately proceed to tackling technology risks &ndash; especially performance or scale. &nbsp;Or, the team may zero in on usability risks. &nbsp;They know this change involves a complex work-flow and they&rsquo;re nervous about that so they want to dive in there.</p>
<p class="p1">Those are both legitimate risks, but they&rsquo;re far from the only risks, and at least in my experience, those are often the easier risks to tackle.</p>
<p class="p1">We must also consider <em>value</em> risk &ndash; do the customers actually want this particular problem solved, or is our proposed solution good enough to get people to switch from what they have now?</p>
<p class="p1">And then there&rsquo;s the often messy <em>stakeholder</em> risk where we have to make sure that the solution we come up with in discovery actually works for the different parts of the company. &nbsp;Here are some common examples of that:</p>
<p class="p1">- Financial risk &ndash; can we afford this solution?</p>
<p class="p1">- Business development risk &ndash; does this solution work for our partners?</p>
<p class="p1">- Marketing risk &ndash; is this solution consistent with our brand?</p>
<p class="p1">- Sales risk &ndash; is this solution compatible with our go to market strategy?</p>
<p class="p1">- Legal risk &ndash; is this solution something we can legally actually do?</p>
<p class="p1">- Ethical risk &ndash; is this solution something we should do?</p>
<p class="p1">Again, for many things we won&rsquo;t have concerns along these dimensions, but when we do, it&rsquo;s something that we need to tackle aggressively.</p>
<p class="p1">If the product manager, designer and tech lead do not feel there&rsquo;s a significant risk for any of these areas, then normally we would just proceed to delivery, fully realizing there&rsquo;s a chance the team will occasionally be proven wrong. &nbsp;However, this is preferable to the alternative of having the team be extremely conservative and testing every assumption. &nbsp;We like to use our discovery time and validation techniques for those situations where we know there&rsquo;s a significant risk, or where members of the team disagree.</p>
<p class="p1">There is a very rich example of this in the news of late. &nbsp;You&rsquo;ve no doubt all heard of the fake news problem on Facebook. &nbsp;Imagine you&rsquo;re on a product team tasked with tackling this very difficult problem. &nbsp;Certainly there&rsquo;s very promising technologies, such as natural language processing, and machine learning more generally, that may be able to help. &nbsp;And that&rsquo;s what most people are talking about right now, but there are some broader issues as well: &nbsp;Who gets to define truth? &nbsp;Is it even appropriate for Facebook to take on that role? &nbsp;And how does all of this mesh with Mark Zuckerberg's product vision? &nbsp;Are there freedom of speech concerns (real or perceived)? &nbsp;How does this get reconciled with different cultural norms around the world, and even censorship? &nbsp;What are the financial implications of restricting monetization on news stories? &nbsp;What are the sales channel implications?</p>
<p class="p1">These are all very real risks that will substantially impact any proposed solution. &nbsp;This gets to the heart of what makes product difficult, and why tackling these risks in discovery is so critical to coming up with solutions that work not just for your customers, but for your company as well.</p>Mon, 28 Nov 2016 13:49:00 -0500http://www.svproduct.com/planning-product-discovery/Pilot Teamshttp://www.svproduct.com/pilot-teams/
<p class="p1">NOTE: This article is by SVPG Partner Chris Jones. &nbsp;He specializes in helping organizations and teams transform to raise their game. &nbsp;This is the first in a series he's writing on this critical topic. &nbsp;This technique is fairly straight forward, but is one of the most powerful tools to introduce substantial change.</p>
<p class="p1"><span style="-webkit-text-stroke-width: initial;">At SVPG, we often work with product leaders who recognize that the way their companies create products needs to change. Oftentimes this happens with a leader who has inherited an organization that needs to be realigned or even turned around. At the same time this leader is creating products, she is also transforming her entire organization and processes around new models of product discovery and development. This realignment can be complex and often impact organizational structures, product planning, delivery processes, and culture.&nbsp;</span></p>
<p class="p1"><strong style="-webkit-text-stroke-width: initial;">Adoption Life Cycle</strong></p>
<p class="p2"><span style="-webkit-text-stroke-width: initial;">If you&rsquo;re in this situation, you should consider the rollout as carefully as you consider your desired end state. The technology adoption lifecycle also applies to organizational change. Some people in the organization love change, some hate it, some need higher levels of evidence, and some just need time to digest the change. If you get too excited and roll out a significant change to everyone in the organization at once, then the laggards (those that hate change) may resist or even sabotage your efforts.</span></p>
<p class="p2"><strong style="-webkit-text-stroke-width: initial;">Pilot Teams</strong></p>
<p class="p1"><span style="-webkit-text-stroke-width: initial;">Readers of these articles understand that great products are seldom planned, designed, developed, and delivered all at once in a huge waterfall. Just like creating a great product, successful organizational transformation requires that teams experiment, iterate, validate, and leverage what is learned into the wider rollout. In other words, it requires being agile (that&rsquo;s agile with a small &ldquo;a&rdquo;)</span><span style="-webkit-text-stroke-width: initial;">&nbsp;</span></p>
<p class="p2"><span style="-webkit-text-stroke-width: initial;">One of the simplest techniques for facilitating transition is pilot teams. Pilot teams allow the roll out of one or more aspects of a transformation to a limited part of the organization before implementing it more broadly.</span></p>
<p class="p2"><span style="-webkit-text-stroke-width: initial;">Perhaps you are implementing a process of dual-track agile and continuous discovery. Or maybe you want to make individual teams accountable for delivering against business impact goals rather than features or roadmaps. Rather than roll out these changes to the entire product organization all at once, start with a small number of pilot teams (often just one) and leave the rest of the organization to operate status quo.</span><span style="-webkit-text-stroke-width: initial;">&nbsp;</span></p>
<p class="p2"><strong style="-webkit-text-stroke-width: initial;">Choose the Teams</strong></p>
<p class="p1"><span style="-webkit-text-stroke-width: initial;">You can modify existing teams or form brand new ones. Selecting the teams depends on your specific goals. Consider these criteria:</span></p>
<ul class="ul1">
<li class="li1"><span class="s1">People: The success of any pilot team starts with the team members. A dedicated product manager, UX designer and lead developer are usually critical, and depending on your goals there will likely be additional roles. Consider the specific individuals who will be filling those roles. Do they have the skills and mindset to drive the pilot team&rsquo;s success? Most importantly, are they enthusiastic about the change? <br /> </span></li>
<li class="li1"><span class="s1">Location: Effective teams need close, cross-functional collaboration. Are the members of the team able to sit together? This means not just in the same city or office, but physically next to one another.<br /> </span></li>
<li class="li1"><span class="s1">Charter: What is the scope of the product team&rsquo;s responsibility? To what extent can the work of the team be framed in terms of business outcomes vs. features or tasks?<br /> </span></li>
<li class="li1"><span class="s1">Autonomy: How much will the work done by the team be dependent on other parts of the organization? Can you set up your teams to minimize dependencies?. Fewer dependencies allow the team to focus on the actual models or techniques you are piloting</span></li>
</ul>
<p><strong style="font-family: Verdana; -webkit-text-stroke: #000000;">Learn</strong></p>
<p class="p2"><span style="-webkit-text-stroke-width: initial;">Once the teams are selected, let them run in the new model for one to two quarters. During this time, it&rsquo;s important to insulate the pilot teams from legacy processes. This is not always easy, but it&rsquo;s mandatory for giving the pilot teams a chance to succeed with the new model.</span><span style="-webkit-text-stroke-width: initial;">&nbsp;</span></p>
<p class="p2"><span style="-webkit-text-stroke-width: initial;">Pay close attention to what&rsquo;s working and what&rsquo;s not. Adjust your course (and iterate!) accordingly. Your specific success measures will depend on your goals, but ultimately you&rsquo;re looking to compare effectiveness in delivering business outcomes, i.e. - how much do the pilot teams movex the business metrics they are are responsible for? How does this compare to your status quo?</span></p>
<p class="p2"><span style="-webkit-text-stroke-width: initial;">Given the nature of the experiment, your comparisons will often be qualitative, but that doesn&rsquo;t make them any less compelling. After one to two quarters the benefit of the new approach should be clear and the pilot teams will either lead the way to a broader transformation or tell you what&rsquo;s in the way of change.</span></p>
<p class="p2">&nbsp;</p>Wed, 02 Nov 2016 20:14:00 -0400http://www.svproduct.com/pilot-teams/Why Women Make The Best Product Managershttp://www.svproduct.com/why-women-make-the-best-product-managers/
<p class="p1"><span class="s1">Recently I gave a keynote address to the&nbsp;<a href="http://www.svpg.com/behind-every-great-product"><span class="s2">Mind The Product Conference in London</span></a>, and in that talk I wanted to illustrate, by example, the essential role that very strong product managers play for their team and their company. &nbsp;Most people noticed that all six of my examples were female. &nbsp;I didn&rsquo;t call that out explicitly during my talk because my view is their performance speaks for itself. &nbsp; But many people did ask me about the gender aspect afterwards (If you haven&rsquo;t yet read that article, I hope you read it first as this article will make much more sense if you know just what traits are necessary for strong product managers).</span></p>
<p class="p2"><span class="s1">When I first started working on the keynote, I realized I had a unique perspective having had the opportunity to work with such a large number of technology product teams for over 35 years.&nbsp; So I wrote a list of all the &ldquo;rock star&rdquo; caliber product managers I knew, and I immediately noticed that more than half my list was female. While females are 50% of the general population, it is not at all representative of the technology product manager population, or of <a href="http://fortune.com/2016/09/27/sheryl-sandberg-women-in-the-workplace/"><span class="s2">corporate America in general</span></a></span><span class="s3">.</span></p>
<p class="p1"><span class="s1">My observation was in no way statistically significant, but it did beg the question if women tend to be so under-represented as product managers, why are so many of them exceptional at the job?&nbsp; Is there something bigger to learn from these women?&nbsp; And ultimately, should more product teams work harder to actively bring in women product managers?</span></p>
<p class="p1"><span class="s1">I have long held opinions on this topic, but this is the first time I&rsquo;m sharing my thoughts publicly. &nbsp;Let me state upfront that what follows are my personal theories about why women so often make the best product managers.&nbsp; Let me also say&nbsp;this entire article is based on generalizations, and I personally know exceptions to each point I make below. &nbsp;But I&rsquo;m putting these theories out there in the hope that people find the points worth considering and discussing.</span></p>
<p class="p1"><span class="s1">As a final disclaimer for those that don&rsquo;t know me, I&rsquo;m male. &nbsp;But I think that makes it easier for me to have this discussion because if a women said the exact same things, it might appear self-serving.</span></p>
<p class="p1"><span class="s1">So I hope people of all genders take this in the spirit it is given. &nbsp;While I am focusing here on the advantages women bring, I strongly believe that every product manager benefits from these traits.</span></p>
<p class="p1"><span class="s1"><strong>Table Stakes</strong></span></p>
<p class="p1"><span class="s1">Just to be clear, I believe strongly that for any product manager, male or female, to be <em>competent</em>, they must be <a href="http://www.svpg.com/behind-every-great-product"><span class="s2"><em>smart, creative and persistent</em></span></a>. &nbsp;This is admittedly a high bar (and far too many teams suffer from the lack of a competent product manager), but I don&rsquo;t see differences across gender in these aspects. &nbsp;</span></p>
<p class="p1"><span class="s1">In this article I&rsquo;m not talking about what makes a competent product manager; I&rsquo;m talking about what&nbsp;distinguishes&nbsp;the competent ones from the <em>best</em>.</span></p>
<p class="p1"><span class="s1">PLEASE NOTE: I am not arguing here that these traits below make someone a better human being; I am just arguing that the product manager job in a tech company is extremely difficult, and that these skills substantially improve your ability to succeed. &nbsp;It's also important to acknowledge that sometimes the way we acquire these skills or traits is not through positive and constructive coaching from a skilled manager or mentor, but rather through very painful lessons learned.</span></p>
<p class="p1"><span class="s1"><strong>BALANCED EGO</strong></span></p>
<p class="p2">In my view, the absolute biggest advantage women have stems from having a well-balanced <em>ego</em>. &nbsp;I&rsquo;ll define that as someone being confident yet modest.&nbsp; It is the rare woman who is over-confident. Even someone as famously accomplished as Sheryl Sandberg didn&rsquo;t assume she was the smartest person in the room (even when she clearly was). Confidence is a necessary ingredient for success, but it is most effective when it doesn&rsquo;t drift towards arrogance, or an over-inflated belief in one&rsquo;s point-of-view.</p>
<p class="p2">One of the main reasons I see otherwise capable product managers fail is due to ego. &nbsp;So much depends on the relationship of the product manager with the other members of the team, and especially with the alpha leaders of the company. &nbsp;It is essential for product managers to not take disagreement as a personal affront. &nbsp;</p>
<p class="p2">The balanced egos many women possess&nbsp;let them hear what&rsquo;s being said without it reflecting as a challenge to themselves. This lets them work effectively&nbsp;with even the alpha males.&nbsp; This balanced sense of self also shows up as women being much more likely to give credit to the team when things go well, yet take the blame on themselves when things go poorly. &nbsp;</p>
<p class="p2">As an example of what&nbsp;I mean here, for each of the six women I highlighted, in every case, their only real hesitation was that readers of my article might not give enough credit to their team.</p>
<p class="p2"><strong>EMOTIONAL INTELLIGENCE</strong></p>
<p class="p2">In a recent <a href="http://www.forbes.com/sites/margiewarrell/2013/12/03/do-women-have-higher-emotional-intelligence-how-to-raise-your-e-q/#ba34664f6fc6"><span class="s3">article </span></a>about Lady Catherine Ashton&rsquo;s crucial role in negotiating Iran halting development of its nuclear program, emotional intelligence is defined as the ability to both identify and manage one&rsquo;s own emotions, pick up on the emotions of others, manage them and, in so doing, build trust, grow influence and achieve better outcomes all round.</p>
<p class="p2">It&rsquo;s not one skill, as much as many skills deployed to navigate people and situations of all types, from brilliant but sometimes dogmatic engineers, to passionate designers, to executives that might be genuinely fearful of, or threatened by, technology, to angry customers, and the many people that just don&rsquo;t like change.</p>
<p class="p2">This emotional intelligence allows the product manager to engage constructively with each of these people, actually listening closely enough to identify the underlying issues and constraints the person is trying to express, and working creatively to find solutions that work for the various parties involved.</p>
<p class="p2">So much about the product role boils down to navigating the complexities of people and constraints to come up solutions that work for customers and work for your company.&nbsp; It&rsquo;s hard to do this consistently without serious emotional intelligence skills.</p>
<p class="p2"><strong>HUMILITY</strong></p>
<p class="p2">You could argue that being humble is a consequence of having a balanced ego, but I think it goes further than that. &nbsp;I would argue that to be a strong product manager, you need to consistently question yourself and your decisions. &nbsp;The truth is we&rsquo;re all very often wrong. &nbsp;Good product managers get that, and are comfortable with that. &nbsp;They even embrace it.</p>
<p class="p2">So often with males, I find them taking it personally when they&rsquo;re wrong on something. &nbsp;Women seem to be much better at separating their personal self-worth, from whether or not particular ideas turn out to work well with customers. &nbsp;This mindset and attitude rubs off on the whole product team, and I believe is a necessary ingredient for consistent innovation.</p>
<p class="p2">Related to this, or maybe because of this, I find that women product managers take self-improvement seriously. &nbsp;Women more naturally bring a growth mindset. In my coaching sessions with women, they tend to be so much more productive because we can talk openly about weaknesses and how to tackle them. &nbsp;All too often I struggle to convince the male product manager that they have a weakness we need to work on.</p>
<p class="p2"><strong>STAMINA</strong></p>
<p class="p2">Anyone that has ever been involved in technology product efforts, especially in larger companies, knows that they are their own sort of marathons.</p>
<p class="p2">To be able to persist for months and usually years, constantly evangelizing, inspiring, problem solving, handling people with difficult personalities at every level of the company, dealing with those that resist change; this takes a special level of stamina. It requires a form of patience, but definitely not acquiescence. &nbsp;Male product managers very often get so frustrated with the sheer duration of the struggle that they eventually lose their composure. &nbsp;Don&rsquo;t get me wrong, it&rsquo;s frustrating for all of us, it&rsquo;s just that I find that women can typically persist much longer.</p>
<p class="p2">So this is my theory as to why I see a disproportionate number of very successful technology product managers that are female. &nbsp;A balanced ego, strong emotional intelligence, humility, and extraordinary stamina.</p>
<p class="p2"><strong>Hiring Women Product Managers</strong></p>
<p class="p2">If you agree with my reasoning, then there&rsquo;s one very important consequence of all this that you&rsquo;ll need to be cognizant of: you need to find ways to encourage more women to <em>apply</em> to product management jobs, even if they haven&rsquo;t done it before.</p>
<p class="p2">I can&rsquo;t tell you how many companies complain to me that they want more women as product managers, but simply not enough women apply for the product jobs.</p>
<p class="p2">Here&rsquo;s the thing: if you post a job for a product manager, many exceptionally qualified women will not actually think they&rsquo;re qualified, and they won&rsquo;t apply. &nbsp;</p>
<p class="p2">For example, if your job description asks for 4 years of technology industry experience, then as a general rule, a man will apply if he has at least 1 year, but a woman will only apply if she has at least 5 years. &nbsp;You may think I&rsquo;m exaggerating on this but I&rsquo;m really not.</p>
<p class="p2">Part of the problem is the job description itself. &nbsp;Many people have obsolete or overly simplistic beliefs about what is required. &nbsp;A degree in computer science is not required. &nbsp;Good understanding of technology and how to apply it to solve problems is required. &nbsp;An MBA is not required. &nbsp;Good understanding of the workings of business is required. &nbsp;Go take a look at the LinkedIn profiles of the six women I highlighted.</p>
<p class="p2">I&rsquo;ve found that I have to actually go and personally approach the women I think are especially well-suited for the product manager job, and explain to them that they really need to apply, and that they should please trust me, that I&rsquo;m really good at spotting talent, and the fact that they are not sure they&rsquo;re prepared for the job, is part of what makes them so good.</p>
<p class="p2">The best women product managers are often those who never thought about doing the job, but are natural fits by how they think, work and act. Find them. Actively recruit them into the discipline. Train and invest in them. Your product teams, your company, and ultimately the entire tech industry will be the better for it.</p>Sun, 16 Oct 2016 22:36:00 -0400http://www.svproduct.com/why-women-make-the-best-product-managers/Behind Every Great Producthttp://www.svproduct.com/behind-every-great-product/
<p class="p1"><span class="s1"><strong>Article: Behind Every Great Product</strong></span></p>
<p class="p1"><span class="s1">When I first decided to start The Silicon Valley Product Group, I had just left eBay and had some very strong opinions about what makes great product teams, and great product cultures, and while there were more than a few important thinkers and leaders on these topics, one area that I felt was under-represented was the role of product management. &nbsp;So one of the very first things I did was to sit down and write an essay about what I believed about this role.&nbsp; I titled the paper, &ldquo;Behind Every Great Product&rdquo; and it was inspired by the classic <a href="http://a16z.com/2012/06/15/good-product-managerbad-product-manager/">Good Product Manager / Bad Product Manager</a>&nbsp;by Ben Horowitz.&nbsp; The paper proved popular and helped many teams to get a better understanding of just what product was all about.</span></p>
<p class="p1">Now, more than a decade later, I&rsquo;d like to revisit this topic.&nbsp; There are three main reasons for this: &nbsp;</p>
<p class="p1"><span class="s1">First, even though&nbsp;I&nbsp;personally spend a good deal of my time writing and coaching and teaching&nbsp;about&nbsp;product management, there&rsquo;s little question&nbsp;that there remains considerable confusion about this role. &nbsp;There are multiple reasons for this but it&rsquo;s simply too important to continue.</span></p>
<p class="p1"><span class="s1">Second, I&rsquo;ve learned a lot in the&nbsp;years&nbsp;since&nbsp;I&nbsp;first wrote about this. &nbsp;I&rsquo;ve had the opportunity to work with many impressive teams and product managers from a broad range of leading tech companies, and this has helped me to get a better sense of the what is essential to the role, and to success.</span></p>
<p class="p1"><span class="s1">Third, I argue that the role is now more essential than ever. &nbsp;I see this role as absolutely critical to success, and very often is the difference between success and failure.</span></p>
<p class="p1"><span class="s1">What has <em>not</em> changed is my overarching belief that behind every great product, there is someone, usually someone behind the scenes, working tirelessly, that is playing this critical role &nbsp;They usually have the title &ldquo;product manager&rdquo; but they might be a startup co-founder or the CEO, or they might be in another role on the team and stepped up because they saw the need.&nbsp; The title is not important; the work they do is.</span></p>
<p class="p1"><span class="s1">There are essentially three ways for a product manager to work, and&nbsp;I argue only one of them leads to success:</span></p>
<ol class="ol1">
<li class="li1"><span class="s1">They can escalate every issue and decision up to the CEO.&nbsp; In this model, the product manager is really <strong>a </strong><em>backlog administrator</em>.&nbsp; Lots of CEO&rsquo;s tell me this is the model they&rsquo;re in and it&rsquo;s not working. &nbsp;If you think the product manager job is what&rsquo;s described in a Certified Scrum Product Owner class, you almost certainly fall into this category.</span></li>
<li class="li1"><span class="s1">They can call a meeting with all the stakeholders in the room and then just let them fight it out &ndash; this is design by committee and it rarely yields anything beyond mediocrity. &nbsp;This is very common in large companies, and in this model, the product manager is really a project manager and&nbsp;<em>roadmap administrator</em>.</span></li>
<li class="li1"><span class="s1">The product manager can do his or her job.</span></li>
</ol>
<p class="p1"><span class="s1">So my intention here is to show you great examples of this third way of working.</span></p>
<p class="p1"><span class="s1">Normally&nbsp;I do this by explaining the critical responsibilities and the necessary character traits and skills, but in this article&nbsp;I will be taking a very different approach. &nbsp;I want to instead introduce you to real people. &nbsp;</span></p>
<p class="p1"><span class="s1">Anyone that&rsquo;s ever worked in product for any amount of time knows that creating products is never easy, but I selected these particular examples to illustrate the very difficult but essential contribution that comes from a strong product manager.</span></p>
<p class="p1"><span class="s1">The products are all iconic, and everyone that reads this will know of every product I describe, but few people know the actual product managers&nbsp;behind these products.&nbsp; And fewer still know the back stories behind these successful products.</span></p>
<p class="p1">I don&rsquo;t think these stories have ever been shared publicly before, and they are stories that I believe deserve to be told.</p>
<p class="p1"><span class="s1">These stories&nbsp;will hopefully&nbsp;show you&nbsp;several examples of product managers doing their job and doing it well. &nbsp;</span></p>
<p class="p1"><span class="s1"><strong>WORD FOR MAC &ndash; Martina Lauchengco</strong></span></p>
<p class="p1"><span class="s1">In 1993, Word 6.0 was the biggest release, feature-wise, Microsoft had ever produced up until then.&nbsp;</span></p>
<p class="p1"><span class="s1">In addition to all the new features, the team had another very large objective.&nbsp; Their code base had diverged and it was extremely slow and costly for Microsoft to be implementing Word separately for each platform: Windows, DOS and Mac.&nbsp; This code convergence effort was supposed to save Microsoft substantial development time, and also - they tried to convince themselves - improve the offering since Word would have the same features on every platform.&nbsp;</span></p>
<p class="p1"><span class="s1">It also meant that there was great pressure to get the release out so they could start to gain the efficiencies of a single code base.</span></p>
<p class="p1"><span class="s1">At the time, Word for Mac was a relatively small market. It was only $60M vs. Windows which at that point was more than a $1B market. &nbsp;</span></p>
<p class="p1"><span class="s1">If you remember back then, Windows machines absolutely dominated, and even the future of Apple was not a sure thing.</span></p>
<p class="p1"><span class="s1">However, the Mac community was also very vocal, with passionate fans of their platform, and is also important to note that this community had very little love for Microsoft. &nbsp;</span></p>
<p class="p1"><span class="s1">PowerMacs were just hitting the market, which had significantly faster chips and more memory.&nbsp; Most of the team were using those new computers because the Word 6.0 beta in it's early days was just too slow on regular Macs.</span></p>
<p class="p1"><span class="s1">Of course, most of the Mac user base was not on new PowerMacs, they were on 'regular' Macs -- hardware upgrade cycles were much slower then. &nbsp;</span></p>
<p class="p1"><span class="s1">So when Microsoft released the most "full-featured word processor ever for the Mac" that&nbsp;<em>crawled</em>&nbsp;on their Macs -- we're talking literally two minutes to startup-- the community immediately started posting in newsgroups that Microsoft was actually trying to "kill the Mac."</span></p>
<p class="p1"><span class="s1">Hate mail started streaming in from everywhere - including emails directly to Bill Gates who would forward them on to the team with messages like "this is depressing MSFT's stock price. Fix it."&nbsp;</span></p>
<p class="p1"><span class="s1">Enter Martina Lauchengco, a young product manager recently out of Stanford,&nbsp;whose job it was&nbsp;to help turn this around.</span></p>
<p class="p1"><span class="s1">The team quickly learned that while it may be a worthwhile objective to get to a common code base, it&rsquo;s an empty victory if the product that results is not good.&nbsp; Moreover, users choose their devices and platforms because they value what's&nbsp;<em>different</em>, not the same.&nbsp;</span></p>
<p class="p1"><span class="s1">From the customer&rsquo;s point of view, they would rather wait a little longer and have a better platform-specific solution, than simultaneously ship a generic product on all platforms.</span></p>
<p class="p1"><span class="s1">The team ended up focusing hard on performance, and taking advantage of what the Mac could do. &nbsp;</span></p>
<p class="p1"><span class="s1">They looked at things like when and how to load fonts since Mac users tended to have so many more than Windows users,&nbsp;and ensuring all Mac keyboard shortcuts still worked.&nbsp;</span></p>
<p class="p1"><span class="s1">They focused on things like Word Count which is used 10 times a day by every press person to make sure that it was lightning fast,&nbsp;as the press used the feature as&nbsp;their performance barometer.&nbsp;They even made it faster than the feature on Windows.</span></p>
<p class="p2">The result was that in a couple of months, they produced a 6.1 release that was sent to every registered user with an apology letter - signed by Martina - along with a discount coupon for future purchases.</p>
<p class="p1"><span class="s1">The release succeeded in fixing the perception problems, but more importantly, it genuinely made the version dramatically better for the Macintosh - a product the Mac team could actually be proud of, and what the team felt they should have delivered to market in the first place.</span></p>
<p class="p1"><span class="s1">This is a good example of how hard it can be to do the right thing for the customer, often in the face of pretty massive pressures, but that&rsquo;s exactly what strong product managers figure out how to do.</span>&nbsp;</p>
<p class="p1"><span class="s1">In subsequent years, not only did Microsoft once again decide to diverge the code base, they completely separated the teams into different buildings and business units, and had them fully embrace all things Mac. &nbsp;Strategically it was a complete 180.&nbsp;</span></p>
<p class="p1"><span class="s1">It&rsquo;s hard to estimate just how important this was to both Microsoft and to Apple.&nbsp; Even today, more than&nbsp;<em>20 years later</em>, many businesses and consumers consider Word&nbsp;and the rest of Office&nbsp;absolutely essential to being able to use their Mac&nbsp;for business and personal use. &nbsp;What started then became a&nbsp;multi-billion dollar win for both Apple and Microsoft. &nbsp;There are more than <em>1 billion Macs and PC&rsquo;s</em> running Office around the world.</span></p>
<p class="p1"><span class="s1">Martina has gone on to have a remarkable career, in both product management and product marketing.&nbsp; From Microsoft she went on to Netscape, where she was responsible for marketing of the Netscape Browser, and then LoudCloud, and now I&rsquo;m happy to say she&rsquo;s been my partner at SVPG for over a decade, and she also teaches marketing at UC Berkeley.</span></p>
<p class="p1"><span class="s1">Let me also add that there&rsquo;s little as powerful as a marketing person that&rsquo;s also strong at product.&nbsp; The combination is amazing.</span></p>
<p class="p1"><strong>NETFLIX</strong>&nbsp;&ndash; <strong>Kate Arnold</strong></p>
<p class="p1"><span class="s1">Netflix is one of my all-time favorite products and companies.</span></p>
<p class="p1"><span class="s1">But back in 1999, a then very young Netflix&nbsp;based in Los Gatos with less than 20 employees, was on the edge of going bust.&nbsp; They had a couple experienced co-founders, including the now legendary Reed Hastings, but the problem was that they were stuck at about 300,000 customers. &nbsp;</span></p>
<p class="p1"><span class="s1">They were essentially providing the same general pay-per-rental experience that Blockbuster provided, just an online version of this.&nbsp; There were, as always, some early adopters, and some people lived in places that didn&rsquo;t have a video store, but in truth there wasn&rsquo;t much of a reason to do this via the postal service when you could just stop by the local Blockbuster store.&nbsp; People would rent once, and then quickly forget about the service, and didn&rsquo;t seem very willing to change.&nbsp; The team knew that the service wasn&rsquo;t better enough to get people to change.</span></p>
<p class="p1"><span class="s1">Even worse, DVD sales were starting to lag, and a Hollywood backlash further muddied the situation. Then there were challenges with fulfillment logistics, difficulty maintaining DVD quality, and trying to figure out how to do all this in a way that covered costs and generated some cash.</span></p>
<p class="p1"><span class="s1">Kate Arnold was the product manager for this small team, and the team knew they needed to do something&nbsp;different. &nbsp;</span></p>
<p class="p1"><span class="s1">One of many tests they tried was to move to a subscription service.&nbsp; Get people to sign up for a month, and offer them unlimited movies.&nbsp; Would that be perceived as &ldquo;better enough&rdquo; to get them to change their media consumption behavior? &nbsp;</span></p>
<p class="p1"><span class="s1">The <em>good news</em> was that yes, actually, this really did appeal to people.&nbsp; A flat monthly fee and all the videos they could consume sounded pretty great.</span></p>
<p class="p1"><span class="s1">The <em>bad news</em> is that the team created some real problems for themselves.&nbsp; No surprise that Netflix customers wanted to rent mostly newly released feature films, yet these were much more expensive for Netflix to stock, and they would need to stock so many copies of these, that they&rsquo;d very likely run out of money fast.</span></p>
<p class="p1"><span class="s1">So the product challenge became how were they going to make sure Netflix customers could watch a set of movies they would love, yet wouldn&rsquo;t bankrupt the company? &nbsp;</span></p>
<p class="p1"><span class="s1">They knew they needed to somehow get customers to want a blend of expensive and less expensive titles. &nbsp;Necessity being the mother of invention,&nbsp;this is where the queue, the ratings system, and the recommendation engine all came from. &nbsp; Those were the technology-powered innovations&nbsp;that&nbsp;<em>enabled</em> the new, much more desirable business model.</span></p>
<p class="p1"><span class="s1">So the team got to work.&nbsp; In three month&rsquo;s time, the team redesigned the site, introducing&nbsp;the queue, the rating system, and the recommendations engine all in support of&nbsp;Netflix being a&nbsp;subscription service.</span></p>
<p class="p1"><span class="s1">They also&nbsp;re-wrote the billing system to handle the monthly subscription model (a funny little side story is that they actually launched without this as they had the 30 day free trial month, which bought them the extra time they needed).</span></p>
<p class="p1"><span class="s1">With so many moving pieces and interconnected efforts, the daily stand-ups included just about every person in the company. &nbsp;</span></p>
<p class="p1"><span class="s1">Between working with the co-founders on the strategy, validating concepts with the users, assessing the analytics, driving features and functionality with the team, and working with finance on the new business model, marketing on acquisition, and the warehouse on fulfillment, you can imagine the workload Kate faced on a daily basis.</span></p>
<p class="p1"><span class="s1">Yet the team got the new service up and running and used this to power and grow their business for another 7 years, until they disrupted themselves again by moving aggressively to the streaming model.</span></p>
<p class="p1"><span class="s1">Kate would be the first to credit a pretty amazing team, including some exceptional engineers, and the vision and courage of the founders, but I would argue that without a Kate driving for the technology-based solutions that could actually power this business, there&rsquo;s a good chance Netflix as we know it never would have happened. &nbsp;This was also a great example of a product manager needing to work across the entire company to come up with not just product solutions but <em>business solutions</em> that work.</span></p>
<p class="p1"><span class="s1">One other interesting little aside about early Netflix &ndash; when they were struggling for cash early on, they offered to sell themselves to Blockbuster for $50M, and Blockbuster turned them down.&nbsp; Today Blockbuster is in the dead pool, and Netflix is worth over $40 <em>billion</em>.</span></p>
<p class="p1"><span class="s1">Kate is now a product leader at Shutterstock in New York City.</span></p>
<p class="p1"><span class="s1"><strong>GOOGLE ADWORDS &ndash; Jane Manning</strong></span></p>
<p class="p1"><span class="s1">This next example is a favorite of mine.</span></p>
<p class="p1"><span class="s1">I&rsquo;m sure all of you have heard of Google&rsquo;s AdWords.&nbsp; You know that this product is what fuels the Google empire.&nbsp; To be specific, AdWords is currently 16 years old, and last year alone it generated well over <em>$50B in revenue.</em></span></p>
<p class="p1"><span class="s1">What I&rsquo;m guessing most of you don&rsquo;t know, however, is just how this industry-defining product actually came to be.&nbsp; And especially how close this product came to never happening at all.</span></p>
<p class="p1"><span class="s1">The year was 2000, and the hardest part about the AdWords project was simply getting agreement that they could work on it.&nbsp;</span></p>
<p class="p1"><span class="s1">The core idea had support from Larry Page, but the idea immediately encountered some pretty strong resistance from both the ad sales team, and the engineering team.</span></p>
<p class="p1"><span class="s1">Jane Manning was a young engineering manager that was asked to serve as product manager for this effort to try to get it off the dime.</span></p>
<p class="p1">The new sales team, under Omid Kordistani, was off to a strong start selling keywords to large brands and placing the results at the top of the search results, highlighted as an ad, but still very prominent, much in the style that had been done in search results at other companies, including at Netscape where Omid came from.&nbsp; Sales was nervous that this idea of a self-service advertising platform would diminish the value of what the sales team was trying to sell.</p>
<p class="p1"><span class="s1">And the engineers, which had been working so hard to provide highly relevant search results, were undersandably very worried that users would be confused and frustrated by ads getting in the way of their search results.</span></p>
<p class="p1"><span class="s1">Jane sat down with each of these people to get a deeper understanding of their concerns.&nbsp; Some were just plain uncomfortable with advertising. &nbsp;Others were worried about cannibalization.&nbsp;</span></p>
<p class="p1"><span class="s1">Once Jane understood the constraints and concerns she was able to advocate for a solution that she believed would address the issues yet enable countless small businesses to get a much more effective advertising solution. &nbsp;Jane also was able to persuade one of Google&rsquo;s earliest and most respected engineers, Georges Harik, of the idea&rsquo;s potential, and he helped to bring along other engineers.</span></p>
<p class="p1"><span class="s1">The product solution&nbsp;they ended up&nbsp;with placed the AdWords-generated ads to the side of the search results, so they wouldn&rsquo;t be confused with the salesperson-sold ads which were displayed on the top of the results.</span></p>
<p class="p1"><span class="s1">Also, instead of determining placement based solely on the price paid, they would use a formula that multiplied the price paid per impression with the ad's performance (click-through-rate) to determine placement, so that the best-performing ads &ndash; the ones most likely to be most relevant to users&nbsp;&ndash;&nbsp;would rise to the top, and the worst ads would be unlikely to be displayed at all, even if they were sold at a higher price.</span></p>
<p class="p1"><span class="s1">This solution clearly differentiated for the sales team, and also ensured quality search results, whether paid or organic.</span></p>
<p class="p1"><span class="s1">Jane actually wrote the first spec for AdWords, and worked side by side with the engineers to build and launch.</span></p>
<p class="p1"><span class="s1">This is yet another example of how there are always so many good reasons for products&nbsp;<em>not</em>&nbsp;to get built. &nbsp;In the products that succeed, there is always someone like Jane behind the scenes working to get over each and every one of the objections, be they technical or business or anything else.</span></p>
<p class="p1"><span class="s1">Jane took a break to start a family and is now back at Google once again, this time helping out the YouTube team.</span></p>
<p class="p1"><span class="s1"><strong>BBC MOBILE &ndash; Alex Pressland</strong></span></p>
<p class="p1"><span class="s1">I have to admit to a soft spot for the BBC.&nbsp; They&rsquo;ve been around for nearly 100 years, but they embraced technology and the Internet relatively early.&nbsp;&nbsp;I&rsquo;ve seen so many amazing product people have come from the BBC, and many are now all over Europe and beyond.</span></p>
<p class="p1"><span class="s1">Back in&nbsp;2003, a full four years before the debut of the iPhone, a young product manager at the BBC, Alex Pressland, had just finished leading a product effort that enabled the BBC to be one of the first media companies in the world to syndicate&nbsp;content. &nbsp;Most people at the BBC had no idea why this was important or even desirable, but Alex understood that this enabling technology could be used in new and unanticipated ways to increase reach for the BBC,&nbsp;a major part of the institution's mission.</span></p>
<p class="p1"><span class="s1">Because she&nbsp;understood the potential for IP-based syndicated content technology,&nbsp;Alex started searching for new and useful ways&nbsp;to put&nbsp;this technology to&nbsp;use.&nbsp; She began by looking at people in the UK that were not being reached by the BBC&rsquo;s conventional broadcast media (TV&rsquo;s and Radios in homes and cars).</span></p>
<p class="p1"><span class="s1">One such early possibility she found&nbsp;were&nbsp;city center venues&nbsp;that had&nbsp;these&nbsp;large electronic billboard screens&nbsp;that were&nbsp;capable of video.&nbsp;&nbsp;But&nbsp;she observed that these venues were just playing the same thing you could watch on your television at home, even though the context and audience was very different.</span></p>
<p class="p1"><span class="s1">So Alex proposed a series of experiments where she would have editorial teams assemble specific tailored content suitable for specific venues and audiences, and then she would measure the audience reach and engagement.&nbsp;</span></p>
<p class="p1"><span class="s1">While this might sound obvious today, at the time this was a very foreign concept to the BBC&rsquo;s&nbsp;<em>broadcast</em>&nbsp;journalism culture, and there were a long list of obstacles in trying to push the BBC in this direction, not the least of which was editorial and legal.</span></p>
<p class="p1"><span class="s1">Editorial wasn't used to the model where content would be created and then delivered in different contexts.&nbsp; This gets to the heart of the BBC editorial culture, and required considerable persuasion to show why this was a very good thing for both the BBC and for the audience.</span></p>
<p class="p1"><span class="s1">Legal wasn't used to distribution via IP enabled devices.&nbsp; Imagine the stack of content licensing agreements that would need to be updated or renegotiated.</span></p>
<p class="p1"><span class="s1">The results of Alex&rsquo;s experiments and early successes gave Alex the confidence to propose to the BBC leadership a new product vision and strategy which she called &ldquo;BBC Out Of Home.&rdquo; &nbsp;</span></p>
<p class="p1"><span class="s1">It&rsquo;s important to note that she did this as an <em>individual contributor</em> product manager.</span></p>
<p class="p1"><span class="s1">This work ended up fueling a dramatic shift at the BBC from broadcast content to content distribution, and this work dramatically impacted reach, and soon became the basis for BBC&rsquo;s Mobile efforts. &nbsp;Today more than 50 million people around the world depend on BBC&rsquo;s mobile offering every week.</span></p>
<p class="p1"><span class="s1">This is not just a story about applying technology to solve problems, but it&rsquo;s also a story about the power of <em>force of will</em>.&nbsp; Especially with large and long-established institutions, it is never easy to drive substantial change, but this is exactly what strong product managers figure out how to do.</span></p>
<p class="p1"><span class="s1">Alex went on from the BBC to have a terrific career at several tech and media companies, and now runs product for Bauer Xcel Media in New York.</span></p>
<p class="p1"><strong>APPLE ITUNES &ndash; Camille Hearst</strong></p>
<p class="p1"><span class="s1">I&rsquo;d love to introduce you to another very strong&nbsp;product manager, Camille Hearst. &nbsp;</span></p>
<p class="p1"><span class="s1">Camille was a product manager on the iTunes team at Apple, and as you might imagine with such a disruptive and ground-breaking product, she experienced and learned a great deal during her formative product years at Apple,&nbsp;especially as she was there during the years moving from the iTunes original DRM-based music, to DRM-free, was critical in helping iTunes to become truly mass market.</span></p>
<p class="p1"><span class="s1">Moving beyond early adopters into mass market involved many different efforts, some product, some marketing, and some a blend of the two.&nbsp; A good example of this blend was the relationship the iTunes team engaged with the American Idol program. &nbsp;</span></p>
<p class="p1"><span class="s1">This turned out to be one of the most dramatic and visible &ndash; yet challenging product efforts for the iTunes team.</span></p>
<p class="p1"><span class="s1">During 2008, American Idol was a cultural icon &ndash; watched by more than 25 million people twice a week, with a level of repeat engagement that was largely unrivaled.</span></p>
<p class="p1"><span class="s1">Apple saw in this an opportunity to expose an ideal target market to the power of iTunes and digital music.&nbsp; Not just by selling the music from the contestants featured on the show, but by making iTunes an integral part of consumer&rsquo;s life.</span></p>
<p class="p1"><span class="s1">However, while the potential was substantial, the challenges were significant as well. &nbsp;</span></p>
<p class="p1"><span class="s1">The VP of&nbsp;iTunes,&nbsp;Eddy Cue,&nbsp;and others made the business deal, but&nbsp;Camille worked as product manager on many of the integrations to help figure this out.</span></p>
<p class="p1"><span class="s1">As just one example, the American Idol program is all about voting, and Apple quickly realized that sales of contestant&rsquo;s music would very likely be strongly indicative of voting results, and while normally iTunes was designed to show trending music and highlight popular titles, in this case it was important to use extreme care to <em>not</em> influence the voting. &nbsp;</span></p>
<p class="p1"><span class="s1">This was obviously critically important to the Idol producers - it would reduce or even eliminate the suspense to learn which contestants would continue to the next week.</span></p>
<p class="p1"><span class="s1">The integration also allowed the team to target a very specific persona, and work to drive up engagement with this group.&nbsp; One of the keys was to make it easy to get to iTunes for those that didn&rsquo;t yet have the app installed.</span></p>
<p class="p1"><span class="s1">By tackling these and countless other challenges head on, Camille and her team were able to come up with technology solutions that complemented the American Idol experience, yet also injected iTunes as a key component of fan&rsquo;s life. &nbsp;This contributed to what was in 2014, before the move to streaming, a roughly <em>$20 billion business.</em></span></p>
<p class="p1"><span class="s1">To me this is a great example of how great product managers work to find creative solutions to very difficult problems.</span></p>
<p class="p1"><span class="s1">Camille went on to join the YouTube team, and then lead product at London-based Hailo, and now I&rsquo;m very happy to say that she&rsquo;s the new CEO of NYC-based startup, Kit.</span></p>
<p class="p2"><strong>ADOBE CREATIVE CLOUD</strong>&nbsp;<strong>&ndash; Lea Hickman</strong></p>
<p class="p2"><strong></strong>It is worth noting that so far,&nbsp;<em>all</em>&nbsp;of these product managers demonstrated exceptional results as&nbsp;<em>individual contributor product managers</em> -- no Director or VP titles. &nbsp;</p>
<p class="p1"><span class="s1">For startups or smaller companies, often all it takes is a strong product team with a strong product manager, but in larger companies, in truth it usually takes more than that.&nbsp; It takes strong <em>product</em>&nbsp;<em>leadership, </em>in the best sense of the word, including providing a compelling product vision and strategy.</span></p>
<p class="p1"><span class="s1">One of the absolute hardest assignments in our industry is to try to cause dramatic change in a large and successful company.&nbsp; It&rsquo;s actually easier in many ways if the company is in serious trouble and they are feeling big pain, because that pain can be used to motivate the change. &nbsp;</span></p>
<p class="p1"><span class="s1">But of course great companies want to disrupt themselves before they&rsquo;re disrupted by others. &nbsp;The difference between Amazon, Netflix, Google, Facebook and the legions of large but slowly dying companies is usually exactly that, product leadership.</span></p>
<p class="p1"><span class="s1">The story I&rsquo;d like to tell you about here is of a product leader, Lea Hickman.&nbsp; In the year 2011, Lea was leading product for Adobe&rsquo;s Creative Suite.</span></p>
<p class="p1"><span class="s1">She had helped Adobe to build a very large and successful business for itself - on the order of $2B in annual license revenue - with its desktop&ndash;based Creative Suite.</span></p>
<p class="p1"><span class="s1">But Lea knew the market was changing, and the company needed to move from the old desktop-centric, annual upgrade model, to a subscription-based model supporting all the devices designers were now using &ndash; including tablets and mobile in all their many form factors.</span></p>
<p class="p1"><span class="s1">More generally, Lea knew that the upgrade model was pushing the company to take the product in directions that were not good for Adobe customers and not good in the long-term for Adobe either.&nbsp; But change of this magnitude &ndash; revenue from Creative Suite was roughly half of Adobe&rsquo;s overall $4B in annual revenue &ndash; is brutally hard. &nbsp;</span></p>
<p class="p1"><span class="s1">Realize that every bone and muscle in the corporate body works to protect that revenue, and so a transition of this magnitude means pushing the company far outside it&rsquo;s comfort zone &ndash; finance, legal, marketing, sales, technology &ndash; few in the company would be left untouched.</span></p>
<p class="p1"><span class="s1">You can start with the typical concerns:</span></p>
<p class="p1"><span class="s1">The finance staff was very worried about the revenue consequences of moving from a license model to a subscription model.</span></p>
<p class="p1"><span class="s1">The engineering teams were worried about from moving from a two-year release train model to continuous development and deployment.&nbsp; Especially while assuring quality.&nbsp; They were also concerned that responsibility for service availability was now going to be much higher.</span></p>
<p class="p1"><span class="s1">There were also big concerns on the sales side, it was expected that this transition would change the way the Creative Suite products were actually sold.&nbsp; Rather than a large reseller channel, Adobe would now have a direct relationship with their customers. &nbsp;While many people at Adobe generally looked forward to this aspect, the sales organization knew that this was very risky in that if things didn&rsquo;t work out well, the channels would probably not be very forgiving.</span></p>
<p class="p1"><span class="s1">And don&rsquo;t underestimate the emotional changes &ndash; to both customers and sales staff - of moving from &ldquo;owning software&rdquo; to &ldquo;renting access&rdquo;.</span></p>
<p class="p1"><span class="s1">With over a million customers of the existing Creative Suite, Lea understood the technology adoption curve, and that there would be a segment of the customer base that would strongly resist a change of this magnitude.&nbsp; Lea understood that it&rsquo;s not just about whether the new Creative Cloud would be &ldquo;better,&rdquo; it would also be&nbsp;<em>different</em>&nbsp;in some meaningful ways, and some people would need more time to digest this change than others.</span></p>
<p class="p1"><span class="s1">Realize also that the Creative Suite is, as the name implies, a&nbsp;<em>suite</em>&nbsp;of integration applications &ndash; 15 major ones and many smaller utilities.&nbsp; So this meant that not just one product had to transform, but the full suite needed to transform, which dramatically increased the risk and complexity.</span></p>
<p class="p1"><span class="s1">It is any wonder that most companies refuse to tackle something of this magnitude?</span></p>
<p class="p1"><span class="s1">Lea knew she had a tough job in front of her and her teams.&nbsp; She realized that in order for all of these inter-related pieces to be able to move together in parallel, she needed to very clearly articulate a compelling vision of the new whole as greater than the sum of the parts.</span></p>
<p class="p1"><span class="s1">Lea worked with Adobe&rsquo;s then CTO, Kevin Lynch, to put together some very compelling prototypes showing the power of this new foundation, and used this to rally both executives and product teams.</span></p>
<p class="p1"><span class="s1">Lea then began a sustained and exhausting campaign to continuously communicate with leaders and stakeholders across the entire company.&nbsp; To Lea, there was no such thing as over-communication.&nbsp; A continuous stream of prototypes helped keep people excited about what this new future would bring.</span></p>
<p class="p1"><span class="s1">Due to the success of the Creative Cloud - Adobe generated more than $1B in recurring revenue faster than anyone else has - Adobe discontinued new releases of the desktop&ndash;based Creative Suite to focus all of their innovation on the new foundation, and today more than 6 million creative professionals subscribe to, and depend on, the Creative Cloud.&nbsp; Today, thanks in large part to this transition, Adobe has more than&nbsp;<em>tripled</em>&nbsp;the market cap it had before the transition &ndash; the company today is worth roughly $50 billion.</span></p>
<p class="p1"><span class="s1">It is easy to see how big companies with lots of revenue at risk would hesitate to make the changes they need to not only survive, but thrive.&nbsp; Lea tackled these concerns and more head on with a clear and compelling vision and strategy, and clear and continuous communication to the many stakeholders.</span></p>
<p class="p1"><span class="s1">This is one of the most impressive, nearly super-human, examples I know of a product leader driving massive and meaningful change in a large and established company.</span></p>
<p class="p1"><span class="s1">There&rsquo;s no question in my mind that Adobe would not be where it is today without someone like Lea working tirelessly to push this change through.</span></p>
<p class="p1"><span class="s1">Lea has moved from Adobe to leading product for a rapidly rising star in our space, a company and product line many of you know and love, InVision.</span></p>
<p class="p1"><strong>SUMMARY</strong></p>
<p class="p1"><span class="s1">Now in every case I just described, each of the product managers went out of their way to emphasize to me just how amazing their team was, and how in no way was the success due to their efforts alone, but hopefully these examples help make clear to you the <em>true and essential contribution</em> of the product manager. &nbsp;</span></p>
<p class="p1"><span class="s1">The big points I hope you take away from this are:</span></p>
<p class="p1"><span class="s1">1) Product Management is absolutely distinct from the other disciplines.&nbsp; It&rsquo;s clearly different than the contribution of the designers, so please let&rsquo;s stop having all the misguided discussions of overlap between those roles. &nbsp;It&rsquo;s also clearly not a project manager. &nbsp;There is some amount of project management&nbsp;inevitably involved just as there is for all leadership positions, but to characterize this as a project manager is to completely miss the essence of the role.&nbsp; The role I would argue that the product manager is most similar to is the role of the CEO.&nbsp; But with the obvious difference that unlike the CEO, nobody reports to the product manager.</span></p>
<p class="p1"><span class="s1">2) Like a CEO, the Product Manager must deeply understand all aspects of the business.&nbsp; The Product Manager needs to ensure a business <em>outcome</em>, not just ensure a product gets defined. This requires&nbsp;a good understanding of the many inter-related parts and constraints of the business &ndash; financial, marketing, sales, legal, partnership, service, the customer environment, the technical capabilities, the user&rsquo;s experience, and figure out a solution that works for the customers as well as the business. But don't think this means an MBA is required - actually not one of the impressive product managers I described has an MBA - or that you need to have all these skills yourself; you must simply have a broad understanding of how a product can affect a business, and work with people from your team and across your company to cover everything that's important.</span></p>
<p class="p1"><span class="s1">3) I hoped you noticed that in literally every one of these examples, the winning solutions didn't come from users or sales; rather great products require an intense collaboration with design and engineering to solve real problems for our users and customers, in ways that meet the needs of your business. &nbsp;In&nbsp;each&nbsp;of these examples, the users had no idea the solution they fell in love with was actually possible.</span></p>
<p class="p1"><span class="s1">4) Like a successful CEO, the successful product manager must be the very best versions of <em>smart</em>, <em>creative</em> and <em>persistent</em>. By <em>smart</em> I mean using new technologies to reach new audiences or enable new business models. By <em>creative</em>, I mean thinking outside the normal product box of features to solve business problems. &nbsp;And <em>persistent</em> -- as in pushing companies way beyond their comfort zone with compelling evidence, constant communication and building bridges across functions in the face of stubborn resistance. &nbsp;Being a great product manager means having extraordinary <em>grit</em>.</span></p>
<p class="p1"><span class="s1">5) Finally,&nbsp;I hope you can see that true&nbsp;<em>leadership</em> is a big part of what separates the great product people from the merely good ones. &nbsp;So no matter your title or level, if you aspire to be great, don't be afraid to&nbsp;<em>lead</em>.</span></p>
<p class="p1"><span class="s1">I&rsquo;ve shown you 6 examples of strong product managers at work as they created products that literally changed the world.</span></p>
<p class="p1">If you want to create ground breaking products at your company, I&rsquo;m hoping their examples show you just what your job truly is, and what a difference great product management can make to a company's success.</p>Fri, 30 Sep 2016 10:43:00 -0400http://www.svproduct.com/behind-every-great-product/The Product Designer Rolehttp://www.svproduct.com/the-product-designer-role/
<p class="p1"><span class="s1"><strong>The Product Designer Role</strong></span></p>
<p class="p1"><span class="s1">You got the go ahead to hire some in-house designers. That&rsquo;s great news! Up until now you&rsquo;ve been relying on an external agency for the majority of your design work and this is going to enable you to create a team that is much more responsive and predictable.</span></p>
<p class="p1"><span class="s1">Your next task is to define the product design role within your company. This is an important one to get right. You don&rsquo;t want to simply recreate an internal version of the agency model. The way that products are created has changed dramatically in recent years and new models for design are a critical part of this.</span></p>
<p class="p1"><span class="s1">Here's a short list of important attributes of the modern product designer role:</span></p>
<p class="p1"><span class="s1"><strong>(1) Product Orientation</strong></span></p>
<p class="p4">In the old model, designers took requirements or specifications from product managers and used that to create their designs. Modern product designers continuously collaborate with product managers and engineers. Rather than work on the latest project in &ldquo;design phase&rdquo; (ironic quotes), the modern product designer participates in all phases of a product, from discovery to delivery to iteration. Rather than sitting with fellow designers, the modern product designer sits together with his or her product manager and if at all possible the team of engineers building the product. Rather than being measured on the output of their design work, the product designer is measured on the success of their product.&nbsp;</p>
<p class="p1"><span class="s1">Given this, good product designers have many of the same concerns as product managers. They are deeply oriented around actual customers and the value their product is bringing to those customers. They also understand that the product is in service of a business and can incorporate those concerns and constraints into the design of a product. Designers further understand that the user experience is as important to customer value as the underlying functionality.&nbsp;</span></p>
<p class="p1"><span class="s1"><strong>(2) Holistic Experience Design</strong></span></p>
<p class="p1"><span class="s1">User Experience (UX) is much bigger than User Interface (UI). Some people even use the term &ldquo;Customer Experience&rdquo; to further emphasize the point. UX is any way that customers and end-users realize the value provided by your product. It includes all the touchpoints and interactions a customer has with your company and product over time. For modern products, this usually includes multiple different UI&rsquo;s (web, mobile, desktop, etc.) as well as other customer touch points (email, customer support, notification, online storage integration, etc.). With some products, UX also includes offline services like riding in an car summoned through Uber, or staying in a house sourced through AirBnB.</span></p>
<p class="p1"><span class="s1">Good product designers anchor their work with a broad view of UX. They think about the customer's journey over time as they interact with the product and company as a whole. Depending on the product, the list of touch points could be very long. Good product designers consider questions like:</span></p>
<ul class="ul1">
<li class="li1"><span class="s1">how will customers first learn about the product?<br /> </span></li>
<li class="li1"><span class="s1">how will we onboard a first-time user and (perhaps gradually) reveal new functionality?<br /> </span></li>
<li class="li1"><span class="s1">how might users interact at different times during their day?<br /> </span></li>
<li class="li1"><span class="s1">what other things are competing for the user&rsquo;s attention?<br /> </span></li>
<li class="li1"><span class="s1">how might things be different for a 1-month old customer differ from a 1-year old customer?<br /> </span></li>
<li class="li1"><span class="s1">how will we motivate a user to a higher level of commitment to the product?<br /> </span></li>
<li class="li1"><span class="s1">how will we create moments of gratification?<br /> </span></li>
<li class="li1"><span class="s1">how will a user share their experience with others?<br /> </span></li>
<li class="li1"><span class="s1">what is it like to resolve a support issue?<br /> </span></li>
<li class="li1"><span class="s1">how will customers receive an offline service?<br /> </span></li>
<li class="li1"><span class="s1">what is the perceived responsiveness of the product?<br /> </span></li>
</ul>
<p class="p3"><strong>(3) Prototyping</strong></p>
<p class="p1"><span class="s1">One of the most important tools of modern product teams are prototypes. Discovering products that customers love requires continuous collaboration with colleagues as well as frequent validation with external users and customers. Prototypes provide the vehicle to facilitate that communication. They are a far more accurate representation of intent than wireframes or screenshots as they are able to capture many other aspects of the full user experience.</span></p>
<p class="p3">Prototyping used to require engineers, but the quality of prototyping tools has improved so much that this is no longer the case. There are some exceptions, but today the majority prototypes don&rsquo;t require engineers. &nbsp;Instead, they are created by designers, and the tools they have available to them have improved dramatically. Good product designers use prototypes as their primary canvas for communicating ideas both internally and externally. They are generally comfortable with a number of different prototyping tools, and able to apply the correct one for the task at hand.</p>
<p class="p1"><span class="s1"><strong>(4) User Testing</strong></span></p>
<p class="p1"><span class="s1">Good product designers are constantly testing their ideas with real users &amp; customers. They don&rsquo;t just test when a prototype or idea is ready, they build testing into their weekly schedule. The regular cadence means that they&rsquo;re able to constantly validate and refine ideas as well as collect new insights that they may not have even been looking for. It also means that they aren&rsquo;t as likely to become too attached to ideas before they come in contact with objective outside opinions.</span></p>
<p class="p1"><span class="s1">User testing is much broader than usability testing. Product designers and their product teams utilize the opportunity to assess the <em>value</em> of their ideas. Will customers actually use or buy the product and if not, what would it take?</span></p>
<p class="p1"><span class="s1"><strong>(5) Interaction <em>and</em> Visual Design</strong></span></p>
<p class="p1"><span class="s1">Visual design and interaction design have historically been considered separate roles. Visual design includes things like composition, typography and how the visual brand is expressed. Interaction design generally includes things like the underlying conceptual models (e.g. a photo management application may have &ldquo;photos&rdquo;, &ldquo;albums&rdquo;, &ldquo;projects&rdquo;, etc.), task flows and control layouts to manipulate those concepts.&nbsp;</span></p>
<p class="p1"><span class="s1">Modern product designers may have different strengths, but generally have some level of skill with both visual and interaction design. Having a more complete toolset allows them to work quickly at different levels of fidelity depending on the context. It also allows them to design experiences in ways that wouldn&rsquo;t have been possible when thinking of interaction and visual separately. This is particularly important in mobile interfaces where designers must often create new models of interaction that are fundamentally intertwined with the visual design.&nbsp;</span></p>
<p class="p3"><strong>So Now What?</strong></p>
<p class="p1"><span class="s1">This is all well and good you say, but these people are hard to hire. &nbsp;Hiring strong people is always hard work, but just as we need to hire a strong product manager and strong engineers, it is critical to hire a strong product designer.&nbsp;</span></p>
<p class="p1"><span class="s1">It&rsquo;s true that you want to bring strong designers into your organization as quickly as you can, but the burden of strong UX should not come only from them. It also involves the other members of your product team like the product manager and engineers. You can up your game right now by growing awareness and setting expectations on what strong UX involves. Ensure that your engineers and product managers understand that much of the value of the product is in the user experience. Encourage them to think broadly about a holistic experience that starts before the customer even learns of your product. &nbsp;Have them use prototypes and user testing to validate their ideas.</span></p>
<p class="p1">Modern product design is not simply about hiring the staff. It involves moving design front-and-center for your team and your process.</p>
<p class="p5"><span class="s1"><br /></span></p>Mon, 29 Aug 2016 11:28:00 -0400http://www.svproduct.com/the-product-designer-role/Vision vs. Strategyhttp://www.svproduct.com/vision-vs-strategy/
<p class="p1"><span class="s1"><strong>Overview</strong></span></p>
<p class="p1"><span class="s1">In recent articles on <a href="http://www.svproduct.com/product-success/">keys to product success</a>&nbsp;and <a href="http://www.svproduct.com/the-alternative-to-roadmaps/">the alternative to roadmaps</a>&nbsp;I&nbsp;</span><span class="s1">have highlighted that if you want the benefits of product team empowerment and autonomy, then you need to provide each team with the&nbsp;necessary context in which to make good decisions. &nbsp;I&rsquo;ve explained that the context typically needs to be the product vision, and a&nbsp;specific set of outcome-based objectives for each team (OKR&rsquo;s are an effective way to do that).</span></p>
<p class="p1"><span class="s1">I&rsquo;ve already written about <a href="http://www.svproduct.com/when-performance-is-measured-by-results/">outcome-based objectives</a>, and in&nbsp;this article&nbsp;I&nbsp;want to talk more about product vision, and especially how&nbsp;important the role of product strategy is in delivering on the product vision.</span></p>
<p class="p1"><span class="s1"><strong>Product Vision</strong></span></p>
<p class="p1"><span class="s1">The product vision describes the future we are trying to create, typically somewhere between 2 and 5 years out. &nbsp;For hardware or device-centric companies it&rsquo;s usually 5-10 years out. &nbsp;This is not in any sense a spec; it&rsquo;s really a persuasive piece. &nbsp;It might be in&nbsp;the&nbsp;form of a story board, or a narrative like a white paper, or a prototype (referred to as a&nbsp;&ldquo;<em>visiontype</em>&rdquo;). &nbsp;It&rsquo;s primary purpose is to communicate this vision and inspire the teams (and investors and partners) to want to help make this vision a reality.</span></p>
<p class="p1"><span class="s1">When done well, the product vision is one of our most effective recruiting tools, and it&nbsp;serves&nbsp;to motivate the people on your teams to come to work every day. &nbsp;Strong technology people are drawn to an inspiring vision; they want to work on something meaningful.</span></p>
<p class="p1"><span class="s1">You&nbsp;can&nbsp;do some validation of the vision, but it&rsquo;s not the same as the validation of specific solutions we do in product discovery. &nbsp;In truth,&nbsp;buying into&nbsp;a vision is a bit of a leap of faith. &nbsp;You very likely don&rsquo;t know how, or even if, you&rsquo;ll be able to deliver on the vision, but remember you have several years to discover the solutions. &nbsp;At this stage, you should believe it&rsquo;s a worthwhile pursuit. &nbsp;As Jeff Bezos says, you want to be&nbsp;&ldquo;stubborn on the vision, and flexible on the details."</span></p>
<p class="p1"><span class="s1"><strong>Product Strategy</strong></span></p>
<p class="p1"><span class="s1">One of the most basic of all product lessons learned is that trying to please everybody will almost certainly please&nbsp;nobody. &nbsp; So the last thing we should do is embark on a ginormous, multi-year effort to create a release that tries to deliver on the product vision. &nbsp;That would truly be the antithesis of the concept of minimum viable product.</span></p>
<p class="p1"><span class="s1">The product strategy is our sequence of products we plan to deliver on the path to realizing the vision. &nbsp;I&rsquo;m using&nbsp;&ldquo;products&rdquo; here loosely. &nbsp;It might be&nbsp;different versions of the same&nbsp;product, it might be a series of different or related products, or it could be some other set of meaningful milestones. &nbsp;Normally&nbsp;I encourage teams to construct a product&nbsp;strategy&nbsp;around a series of <em><a href="http://www.svproduct.com/product-market-fit/">product-market fits</a></em></span>.</p>
<p class="p1"><span class="s1">There are many variations on this (the strategy for the product strategy, if you will):</span></p>
<p class="p1"><span class="s1">For many B2B SaaS companies, each product-market fit focuses on a different vertical market (e.g. financial services, manufacturing, telco, etc.). &nbsp;</span></p>
<p class="p1"><span class="s1">For consumer companies, we often structure each product-market fit around a different <a href="http://www.svproduct.com/personas-for-product-management/">customer or user persona</a>. &nbsp;</span></p>
<p class="p1"><span class="s1">Sometimes the product strategy is based on geography, where we tackle different regions of the world in sequence.</span></p>
<p class="p1"><span class="s1">And sometimes the product strategy is based more on achieving a set of key deliverable milestones in some sort of logical and important order (e.g. "first deliver critical rating and reviews functionality to developers building e-commerce applications, then leverage the data that is generated from this use to create a database of consumer product sentiment, then leverage this data for advanced product recommendations").</span></p>
<p class="p1"><span class="s1">There&rsquo;s no one approach to product strategy that is ideal for everyone, and you can never know how things might have gone if you ordered your product-market fits differently, but I tell teams that the most important benefit is just that you decided to <em>focus your product work on a single market at a time</em>. &nbsp;So all teams know we&rsquo;re tackling the manufacturing market now, and that&rsquo;s the type of customers we are obsessing on, and our goal is to come up with the smallest actual deliverable product that makes these customers successful. &nbsp;Ideas that pertain to other markets are saved for future consideration.</span></p>
<p class="p1"><span class="s1">Besides significantly increasing your chance of delivering something that can power your business, the product strategy now gives you a tool to align your product work with your sales and marketing organization. &nbsp;We want the sales organization to be selling in the markets that we&rsquo;ve demonstrated product-market fit. &nbsp;As soon as we demonstrate product-market fit for a new market (usually by developing an initial set of <span class="s4"><a href="http://www.svproduct.com/the-power-of-reference-customers/"></a><a href="http://www.svproduct.com/the-power-of-reference-customers/">reference customers</a></span>, the sales force can go out and find more customers in that market.</span></p>
<p class="p1"><span class="s1"><strong>Why are Product Vision and Product Strategy so important?</strong></span></p>
<p class="p1"><span class="s1">So back to the concept of providing context to the product teams.</span></p>
<p class="p1"><span class="s1">In order for a product team to actually be empowered and act with any meaningful degree of autonomy, the team must have a deep understanding of the broader context. This starts with a clear and compelling product vision, and the path to achieving that vision: the product strategy.</span></p>
<p class="p1"><span class="s1">The more product teams you have, the more essential it is to have this unifying vision and strategy in order for each team to be able to make good choices.</span></p>
<p class="p1"><span class="s1">I was with a startup recently and describing the value and importance of vision and strategy, and it occurred to me that it&rsquo;s very&nbsp;analogous to the difference between <a href="http://www.svproduct.com/leadership-vs-management/">leadership and management</a>. &nbsp;Leadership inspires and sets the direction, and management helps us get there.</span></p>
<p class="p1"><span class="s1">Most importantly, the product vision should be&nbsp;<em>inspiring</em>, and the product strategy should be very&nbsp;<em>intentional</em>.</span></p>
<p class="p1"><span class="s1"><strong>Notes</strong></span></p>
<p class="p1"><span class="s1">As you might expect, there are many nuances to product strategy. &nbsp;I want to speak to some of the most important points here:</span></p>
<p class="p1"><span class="s1"><strong>NOTE 1:</strong>&nbsp;In terms of prioritizing markets, all I really said above was to prioritize your markets and focus on one at a time. &nbsp;I didn&rsquo;t say how to prioritize them. &nbsp;There is no one right way to do this, but there are two critical inputs to your decision. &nbsp;The first is market sizing (usually referred to as &ldquo;TAM&rdquo; - total addressable market). &nbsp;All things considered equal, we like big markets rather than small markets. &nbsp;But of course they&rsquo;re not equal. &nbsp;If the largest TAM market would require 2 years of product work, yet several of the somewhat smaller but still significant markets are much closer in terms of time-to-market (&ldquo;TTM&rdquo;), most likely everyone in your company from the CEO and head of sales on down would prefer you deliver on a smaller market sooner. &nbsp;These are typically the two dominant factors but others can be important also. &nbsp;I typically suggest that the head of product, head of technology and head of marketing sit down together to work out your product strategy, balancing these various factors.</span></p>
<p class="p1"><span class="s1"><strong>NOTE 2:</strong>&nbsp;Some people refer to the&nbsp;product strategy as the&nbsp;&ldquo;vision roadmap.&rdquo; &nbsp;No real problem with that other than the use of the term&nbsp;&ldquo;roadmap" can be confusing to the company. &nbsp;Note also that this vision roadmap is&nbsp;very different from a <em>product</em> roadmap (a prioritized set of features and projects intended to deliver on a specific product-market fit in the product strategy).</span></p>
<p class="p1"><span class="s1"><strong>NOTE 3: </strong>Normally when we create the product vision and product strategy, we also create a set of <a href="http://www.svpg.com/the-product-manifesto"><span class="s4">product principles</span></a> (aka "product manifesto&rdquo;). The three components are often lumped together and just referred to as&nbsp;&ldquo;the product vision.&rdquo;</span></p>
<p class="p1"><strong>NOTE 4:</strong> Just because we achieve product-market fit for a specific market does not mean that we are done with&nbsp;work for that market. &nbsp;It just means&nbsp;that we&rsquo;ve got that minimal actual product we can sell that is proven to meet the needs of the initial set of reference customers. &nbsp;We continue to improve the product for other customers in the market. &nbsp;We typically do that work in parallel with tackling the next market in our strategy.</p>Fri, 15 Jul 2016 16:49:00 -0400http://www.svproduct.com/vision-vs-strategy/Technology-Powered Disruptionhttp://www.svproduct.com/technology-powered-disruption/
<p class="p1"><span class="s1">Most people by now have read Marc Andreessen&rsquo;s <a href="http://www.wsj.com/articles/SB10001424053111903480904576512250915629460"><span class="s2">Why Software Is Eating The World</span></a>. &nbsp; This was written back in 2011, and I&rsquo;ve been watching his predictions play out in companies all around the world. &nbsp;While my focus is primarily on technology-powered software products, services and devices, I&rsquo;m also very interested to find other industries where the techniques of modern product are used to disrupt their spaces.</span></p>
<p class="p1"><span class="s1">If you have not yet directly experienced a Tesla, you should absolutely find a way to do at least a test drive. &nbsp;Truly exceptional tech product work, disrupting a very difficult and entrenched industry in so many respects. &nbsp;Of all the amazing technology achievements of the past decades, I personally find this one the most impressive. &nbsp;You can learn more in the recent <a href="https://www.amazon.com/Elon-Musk-SpaceX-Fantastic-Future/dp/0062301233"><span class="s2">Elon Musk</span></a> biography.</span></p>
<p class="p1"><span class="s1">Similarly, if you admire the work of Pixar, you should read the book <a href="https://www.amazon.com/Creativity-Inc-Overcoming-Unseen-Inspiration/dp/0812993012"><span class="s2"><em>Creativity, Inc.</em></span></a> to understand how this amazing company created a culture and the techniques from the best technology companies to consistently create exceptional animated feature films, blending creative talent with technology in the best sense, and in the process disrupting a stagnant industry. &nbsp;I find especially encouraging how Pixar&rsquo;s leadership later brought those same techniques and culture to the buried talent at Disney Animation, which lead to their turnaround. &nbsp;If anyone doubts the power of true leadership and culture, or if you believe that a company that has lost it&rsquo;s product mojo is not capable of finding it again, this is one of my favorite examples.</span></p>
<p class="p1"><span class="s1">Yet another industry that is similarly long overdue for major disruption is medicine. &nbsp;Of course, in some respects we have seen remarkable progress here, in particular in the treatment of specific diseases, but in terms of general medicine it can seem like a hopeless quagmire of insurance companies, pharmaceutical companies, malpractice lawyers, food lobbies, and government intervention. &nbsp;While these institutional issues persist, there is a new branch of medicine which has applied the techniques of technology-powered product, especially data science, personalization, and the principles of rapid test and learn behind discovery, to work to disrupt the health-care industry. &nbsp;One of the pioneering doctors in this space is Silicon Valley&rsquo;s own Dr. Mike Nichols, and he recently released a new book <a href="https://www.amazon.com/Quantitative-Medicine-Complete-Getting-Avoiding/dp/098625200X"><span class="s2"><em>Quantitative Medicine: A Definitive Guide to Getting Well, Staying Well, Avoiding Disease and Slowing Aging</em></span></a><em>. </em>&nbsp;This book represents his life&rsquo;s work in the multi-disciplinary, and inter-related, areas of medicine and lifestyle choices involving nutrition, exercise, sleep and the role of spirituality or meditation. &nbsp;If Google, Facebook, Amazon, (or Tesla or Pixar) were to tackle the problem of general health the way they tackle other hard problems, I believe they&rsquo;d take a similar approach.</span></p>
<p class="p1"><span class="s1">For the past few years I&rsquo;ve been part of a cohort of people testing out the quantitative medicine techniques, so I&rsquo;ve been experiencing it first-hand. &nbsp;I am happy the book is out because it&rsquo;s been exhausting trying to explain the methods to everyone that&rsquo;s been asking. &nbsp;I do think this is an important book for people to read, for their own health and longevity.</span></p>
<p class="p1">Whether it&rsquo;s transportation, entertainment, health care, or any other industry, I fully expect we&rsquo;ll see new companies and teams emerge that apply the techniques of technology-powered products to disrupt their industries. &nbsp;And of course we&rsquo;ll continue to see many long-entrenched players pretend this isn&rsquo;t happening, or spend their energies trying to protect what they have built in the past through litigation and lobbying rather than innovation.</p>Tue, 28 Jun 2016 23:45:00 -0400http://www.svproduct.com/technology-powered-disruption/Tribute to Bruce Williamshttp://www.svproduct.com/tribute-to-bruce-williams/
<p class="p1"><span class="s1">This has been a tough year for the technology industry. &nbsp;In March we lost Andy Grove, and in April we lost Bill Campbell. Sadly, in May we lost <a href="http://www.legacy.com/obituaries/mercurynews/obituary.aspx?n=bruce-lee-williams&amp;pid=180115991&amp;"><span class="s2">Bruce Williams</span></a>. &nbsp;Bruce had been fighting Pancreatic Cancer for the past year and a half. &nbsp;He had been in an experimental program at UCSF, which extended his life at least a year.</span></p>
<p class="p1"><span class="s1">While I learned much from Andy Grove and Bill Campbell, Bruce had an even bigger impact on me, both personally and professionally, probably more than any other single person.</span></p>
<p class="p2">This article is not just a tribute; I want to talk about two very important topics for product people, the first is work-life balance, and the second is your relationship with customers. &nbsp;As you&rsquo;ll see, both of these topics were central to Bruce&rsquo;s work and life.</p>
<p class="p1"><span class="s1">Most people outside of Silicon Valley would not likely have heard of Bruce, but he was a bit of a legend here. &nbsp;He originally was the co-founder and CEO of an early software company, Westminster Software, and then he founded Westminster Promotions, which has been going strong now since 1992, a remarkable 24 years. &nbsp;</span></p>
<p class="p1"><span class="s1">Over the years Westminster has been a trusted marketing partner for literally hundreds of marquee Silicon Valley companies, including: Arista, AT&amp;T, Cisco, EMC, Informatica, LinkedIn, Logitech, Marketo, Marvell, National Semiconductor, NetApp, Palm, Ruckus, Seagate, Stanford, Synopsis, TiVo, and VMWare, to name just a few of those you&rsquo;d recognize.</span></p>
<p class="p2">Personally, Bruce was a long-time close friend of mine, and he was actually the person that convinced me to start The Silicon Valley Product Group, and he helped me in countless ways to make the business successful.</p>
<p class="p1"><span class="s1">I have never written about the &ldquo;work life balance&rdquo; topic before because, to be truthful, I have always considered myself pretty awful at managing this balance. &nbsp;I have not told many people this, because it&rsquo;s nothing to be proud of, but when I was working at eBay, my then three-year-old daughter asked my wife one week-end day, &ldquo;Mommy, where does Daddy live?&rdquo; &nbsp;I knew something had to change, and that planted the seed for what was to become SVPG.</span></p>
<p class="p1"><span class="s1">The whole &ldquo;work life balance&rdquo; discussion never rang true for me. &nbsp;The way I thought about it was that there&rsquo;s only so many hours in a week, and if your job actually requires at least 60 hours a week to do it even reasonably well (which I argue is the case for many roles in the tech industry), then I didn&rsquo;t see how that would leave much time for family and sleep.</span></p>
<p class="p1"><span class="s1">But Bruce showed me another approach, one that provided for a much richer personal life, as well as more satisfaction and enjoyment out of work than I had ever experienced before. &nbsp;I think of his approach as &ldquo;work life integration.&rdquo;</span></p>
<p class="p1"><span class="s1">The key is that work and personal life don&rsquo;t actually need to be so separate, and in fact shouldn&rsquo;t be. &nbsp;You can enjoy very close and rewarding personal relationships with those you work with &ndash; customers, employees, and investors&nbsp;&ndash;&nbsp;and you can often involve your family much more in your career.</span></p>
<p class="p1"><span class="s1">So many of Bruce&rsquo;s customers became true, long-term friends. &nbsp;At his family events I&rsquo;d often see people that I know he first met as customers. &nbsp;They loved (I use that word intentionally and not lightly) Bruce because they knew he genuinely cared about them and their families and their careers. &nbsp;He proved this in ways large and small every day.</span></p>
<p class="p1"><span class="s1">As Bill Campbell used to say, companies care about what their leader cares about, and Bruce cared about people, so his employees cared about people.</span></p>
<p class="p2">Which brings me to his relationship with his employees.&nbsp;</p>
<p class="p2">In an era where the articles you read are often about the &ldquo;gig economy&rdquo; where your workforce is just used on-demand, as needed, and loyalty is an obsolete notion, the relationship Bruce had with his employees may look old-fashioned but it was amazing and extremely effective. &nbsp;Most of Bruce&rsquo;s employees have been with him for more than a decade. &nbsp;Every one of them considered him much more than a manager or the CEO of their company. &nbsp;</p>
<p class="p1"><span class="s1">Bruce not only considered this the ethical way to run a business, but also, in an industry built on relationships, the smart and successful way to run a business. &nbsp;Bruce developed a set of leaders at&nbsp;Westminster that&nbsp;I&nbsp;fully expect will carry on providing the same level of authentic care for their customers for another&nbsp;twenty years.</span></p>
<p class="p2">Moreover, Bruce taught me that customers, investors and employees are more alike than most people think. &nbsp;The investors are trading their money for equity; customers are trading their money for the product or service you provide; and employees that are trading their efforts and loyalty for their livelihood. &nbsp;All are usually doing this in the hopes of a long-term, mutually beneficial relationship.</p>
<p class="p1"><span class="s1">So Bruce had a very large and beautiful network of relationships that blurred the lines between work and life. &nbsp;He also made a conscious effort to involve his family in his work. &nbsp;One way he did that was philanthropy. &nbsp;Bruce involved his family and his employees in working on causes they all believed in. &nbsp;I don&rsquo;t think I&rsquo;ve ever seen a company invest that large of a percentage of their time and services on charity causes.</span></p>
<p class="p1"><span class="s1">So to me it is absolutely not an accident that Bruce was both a very successful entrepreneur, as well as one of the most widely loved people in our industry and our community.</span></p>
<p class="p1"><span class="s1">For the past 20 years I have been actively trying to learn from Bruce, and become more like him. &nbsp;I know I have a long ways to go, but his work and life continues to inspire me.</span></p>
<p class="p3"><span class="s3">Donations in Bruce&rsquo;s name may be made to <a href="http://cancer.ucsf.edu/how-to-help"><span class="s4">The Helen Diller Family Cancer Center at UCSF</span></a>.</span></p>Wed, 01 Jun 2016 07:17:00 -0400http://www.svproduct.com/tribute-to-bruce-williams/Developer Powered Innovationhttp://www.svproduct.com/developer-powered-innovation/
<p class="p1"><span class="s1">There is a very common fallacy about developers in our industry, and I think it hurts countless companies.</span></p>
<p class="p2">Have you ever heard the old accusation that developers only want to solve problems for themselves? &nbsp;They&rsquo;ll spend countless hours, often on their own time, to create amazing tools for themselves and the developers they work with. &nbsp;But just try to get them excited about building something for &ldquo;the business&rdquo; or &ldquo;the customer" and good luck. &nbsp;</p>
<p class="p1"><span class="s1">I&rsquo;ve been accused of this myself. &nbsp;For the first 20 years of my career I was either building tools for other developers, or leading products designed for other developers. &nbsp;It wasn&rsquo;t actually until eBay that I was responsible for creating products for people other than developers.</span></p>
<p class="p1"><span class="s1">I have been increasingly vocal lately about the critical role that developers must play in consistent innovation. &nbsp;I&rsquo;ve been raising the volume on this because despite what I consider overwhelming evidence to the contrary, I continue to find teams where the CEO, the product managers, and the designers think they can figure out the product themselves, and they don&rsquo;t want to &ldquo;bother&rdquo; the engineers with anything that distracts from their coding time.</span></p>
<p class="p1"><span class="s1">I&rsquo;ve written about this several times <a href="http://www.svproduct.com/the-end-of-requirements/">before</a>&nbsp;but while my writing talks about the critical need to include developers, it has not addressed this belief that developers only want to solve problems for other developers.</span></p>
<p class="p1"><span class="s1">Don&rsquo;t get me wrong, it&rsquo;s easy to see where this misconception comes from. &nbsp;Developers get hugely excited about building things for other developers, and progress on the engineering tooling front has been near constant because of that (consider DevOps as just the latest example). &nbsp;So it&rsquo;s easy to see why people think this is all that can excite developers. &nbsp;</span></p>
<p class="p1"><span class="s1">While it&rsquo;s easy to understand where this opinion comes from, I argue it is dead wrong.</span></p>
<p class="p1"><span class="s1">Here&rsquo;s the key:</span></p>
<p class="p1"><span class="s1">It&rsquo;s&nbsp;<em>not</em>&nbsp;that developers only want to build products for themselves. &nbsp;The vast majority of developers are passionate about solving real problems for real people. &nbsp;The problem is that in the vast majority of companies, the only people that the developers are actually exposed to directly on a regular basis are&nbsp;<em>other developers</em>. &nbsp;They see the problems their colleagues are dealing with, and they want to help.</span></p>
<p class="p1"><span class="s1">However, how often do you see the developers brought along to the actual customers?</span></p>
<p class="p1"><span class="s1">I have long said that &ldquo;the magic happens&rdquo; when you connect the developers with the actual users and customers, and let them witness - first hand - the good, the bad and the ugly.</span></p>
<p class="p1"><span class="s1">When a company keeps their developers sheltered from their customers,&nbsp;<em>they are hurting themselves and their customers.</em></span></p>
<p class="p1"><span class="s1"><em></em></span>One of the worst things you can do is try to shelter the developers from the ugly truth. &nbsp;Give them the chance to see the issues themselves, and I am betting you will see a level of motivation and passion around solving the problems that you may not have realized possible.</p>
<p class="p1"><span class="s1">Note that we don&rsquo;t need every developer to engage with customers, but we do need some. &nbsp;It&rsquo;s usually the more senior developers.</span></p>
<p class="p1">One last warning about this. &nbsp;While it&rsquo;s essential to get developers out there interacting directly with your users and customers, you do need to make sure that they know the proper etiquette (for lack of a better word), especially if you have a direct sales organization. &nbsp;It&rsquo;s not unusual to have some form of &ldquo;<a href="http://www.svproduct.com/product-manager-charm-school/">charm school</a>&rdquo; for the developers.</p>Thu, 19 May 2016 20:35:00 -0400http://www.svproduct.com/developer-powered-innovation/Product Successhttp://www.svproduct.com/product-success/
<p class="p1"><span class="s1">Exactly a year ago&nbsp;I was invited to give a keynote at the Craft Conference in Budapest and&nbsp;I discussed the 10 biggest reasons&nbsp;why product teams fail. &nbsp;You can watch that talk <a href="http://www.ustream.tv/recorded/61491014"><span class="s2">here</span></a>, or read the narrative article <a href="http://www.svproduct.com/product-fail/">here</a></span>.</p>
<p class="p1"><span class="s1">As I mainly shined a light on why so many teams are operating so ineffectively, and despite claims to the contrary, most product organizations are hardly &ldquo;agile&rdquo; in any meaningful sense of the term, as the organization overall is still operating in a very waterfall fashion, the conference organizers invited me back again this year to give the sequel, to discuss more about how the best teams I know work. &nbsp;</span></p>
<p class="p1"><span class="s1">Last week I delivered that talk, and this article is a narrative version.&nbsp; If you prefer to watch the video (1 hour long), you can find the presentation <a href="http://ustre.am/:5PvTR"><span class="s2">here</span></a>.</span></p>
<p class="p1">After the first talk quite a large number of people contacted me and asked for more information about the alternative. &nbsp;Other than recommend to people that they read my book or attend a 2 day workshop, I didn&rsquo;t feel like I was able to give a very satisfying answer. &nbsp;So it inspired me to think hard about the most important characteristics of very strong product teams, and I forced myself to pick what I consider the ten most important.</p>
<p class="p1"><span class="s1"><strong>CONTINUOUS DISCOVERY AND DELIVERY</strong></span></p>
<p class="p1"><span class="s1">Just as I described the ten biggest problems in the context of the Waterfall model, I described the ten attributes of successful teams in the context of the <a href="http://www.svpg.com/discovery-vs-delivery"><span class="s2">Continuous Discovery and Delivery</span></a> model (also known as Dual Track Agile, or Discovery Sprints and Delivery Sprints).</span></p>
<p class="p1"><span class="s1"><strong>KEYS TO SUCCESS</strong></span></p>
<p class="p1"><span class="s1"><strong>1. Empowered Product Teams</strong></span></p>
<p class="p1"><span class="s1">The most important characteristic of all is the absolutely fundamental concept of a strong product team. &nbsp;But what does that really mean? &nbsp;</span></p>
<p class="p1"><span class="s1">First, it&rsquo;s essential that the team is <em>durable</em>; the members are not meant to be moved around like chess pieces. &nbsp;If they want to actually innovate, they need the time to get to know each other, their technology, their customers, and the business context.</span></p>
<p class="p1"><span class="s1">Second, the <em>chemistry</em> of the members of the team is key. &nbsp;This means that the know and respect each other enough that every member of the team feels comfortable contributing and raising suggestions, and challenging themselves and each other to do better.</span></p>
<p class="p1"><span class="s1">Third, this means that teams have the necessary <em>skill-set diversity</em>, which is typically product management, user experience design, and engineering. &nbsp;In many cases we would add to this list data analysis and user research.</span></p>
<p class="p1"><span class="s1">Finally, despite being a sensitive topic for many companies, it is hard to argue with the advantages of a <em>co-located</em> team. &nbsp;Co-location means that the product manager, product designer, and the engineers (or at least the tech lead) all sit right next to each other. &nbsp;We can&rsquo;t always achieve co-location for all of our teams, but we try. &nbsp;And just to be clear, having teams in multiple locations is not the issue, it&rsquo;s when a single team is split up that causes the negative impact to both velocity and especially innovation.</span></p>
<p class="p1"><span class="s1"><strong>2. Product Vision and Strategy</strong></span></p>
<p class="p1"><span class="s1">In order for a product team to actually be empowered and act with a meaningful degree of autonomy, the team must have a deep understanding of the broader business context. &nbsp;This starts with a clear and compelling product vision, and a path to achieving that vision, which is referred to as the product strategy.</span></p>
<p class="p1"><span class="s1">The product vision describes the world we are trying to create, typically somewhere between 2 and 5 years out (longer for hardware efforts).</span></p>
<p class="p1"><span class="s1">The product vision must be inspiring. &nbsp;When done well, it is one of our most effective recruiting tools, and motivates people to come to work every day. &nbsp;Strong technology people are drawn to an inspiring vision. &nbsp;They want to work on something meaningful.</span></p>
<p class="p1"><span class="s1">The product strategy is our sequence of products we plan to deliver on the path to realizing the vision. &nbsp;It would be a very poor strategy to try to please everyone with a single product release. &nbsp;Instead, we have a prioritized list of markets, geographies, or personas and we focus on achieving product/market fit for each of these markets.</span></p>
<p class="p1"><span class="s1">The more product teams you have, the more essential is to have this unifying vision and strategy in order for each team to be able to make good choices.</span></p>
<p class="p1"><span class="s1">Most importantly, the product vision should be <em>inspiring</em>, and the product strategy should be very <em>intentional</em>.</span></p>
<p class="p1"><span class="s1"><strong>3. Focus on Business <em>Outcomes</em>&nbsp;</strong></span></p>
<p class="p1"><span class="s1">The second part of the business context that an empowered, autonomous team needs in order to be able to make good decisions is the set of prioritized business objectives. &nbsp;The OKR (Objectives and Key Results) system is intended to facilitate precisely this.</span></p>
<p class="p1"><span class="s1">The OKR&rsquo;s reflect the list of specific <em>business</em> <em>problems</em> that the team is being asked to solve. &nbsp;These are not features. &nbsp;Features are only <em>potential</em> solutions to problems. Launching a feature is not success for a team; solving the actual business problem is. &nbsp;</span></p>
<p class="p1"><span class="s1">The two principles that are behind these performance management techniques are: first, teams will perform better if you give them the problems you need them to solve, rather than give them the solutions; and second, the team is measured by results, not output. &nbsp;Shipping features on a roadmap is output, solving business problems are <em>results</em>.</span></p>
<p class="p1"><span class="s1"><strong><em>4. Competent</em> Product Manager</strong></span></p>
<p class="p1"><span class="s1">Sadly many engineers have never had the opportunity to work with a capable product manager. &nbsp;The ones that have are the ones insisting that they always have such a person on their team. &nbsp;Even worse, many engineers don&rsquo;t even know what the product manager is supposed to be contributing to the team.</span></p>
<p class="p1"><span class="s1">Think of it this way. &nbsp;In order for a product team to solve hard business problems, it&rsquo;s not enough that the solution just work technically, and it&rsquo;s also not enough that the customer loves it, but also, and often most difficult, the solution must actually work for your business.</span></p>
<p class="p1"><span class="s1">Think about what this means. &nbsp;Imagine you are working for Uber or AirBnB and you have to navigate complex laws and unions and trade groups. &nbsp; Or eBay which had to navigate significant constraints to be classified as a marketplace rather than an e-commerce site. &nbsp;Or Tesla which had to navigate liability issues with Autopilot. &nbsp;Every company has a list of these types of constraints. &nbsp;</span></p>
<p class="p1"><span class="s1">There are legal constraints, financial constraints, sales and pricing constraints, brand and marketing constraints, privacy constraints, security constraints, partnership conditions, and the list goes on. &nbsp;</span></p>
<p class="p1"><span class="s1">Unfortunately, in many cases the only person that has done the work to understand all of them is the CEO, and if that&rsquo;s the case, you can imagine why he or she might not feel comfortable truly empowering the team to make decisions.&nbsp;</span></p>
<p class="p1"><span class="s1">There are really three options to how teams work. &nbsp;One is that the CEO or some other exec decides everything. &nbsp;The second is that the weak product manager schedules a big meeting and invites all the executives into a room and they argue it out &ndash; this is called design by committee &ndash; which consistently produces weak results. &nbsp;The third is that the product manager does her job and learns these constraints, and brings them to the team so that the team can figure out the best way to solve the problem.</span></p>
<p class="p1"><span class="s1">Combine this with strong understanding of technology, and deep knowledge of the users and customers, and hopefully you can see why this is a tough job. &nbsp;But also one that&rsquo;s absolutely key to a strong product team especially if the team wants to have any meaningful degree of autonomy.</span></p>
<p class="p1"><span class="s1"><strong><em>5. Collaboration</em>-driven Solutions&nbsp;</strong></span></p>
<p class="p1"><span class="s1">I am not saying &ldquo;collaboration&rdquo; here as a buzzword. &nbsp;What I mean by this is that rather than a product manager handing down &ldquo;requirements,&rdquo; and a designer making things pretty, and engineers just there to code what they are told to, instead, the three skills &ndash; product, design and engineering &ndash; truly collaborate to solve the problems. This is because with good solutions, the technology drives the functionality as much as the functionality driving technology. &nbsp; The technology enables design options as much as design drives technology selection. &nbsp;And design direction drives functionality as much as the other way around.</span></p>
<p class="p1"><span class="s1">The point is that the technology, the user experience design, and the functionality, are all completely intertwined. &nbsp;We come up with good solutions with a constant back and forth, give and take, between the three. &nbsp;</span></p>
<p class="p1"><span class="s1">The need for these collaboration-driven solutions is the single biggest reason why co-located teams consistently out-perform distributed teams.</span></p>
<p class="p1"><span class="s1"><strong>6. Product Discovery: Learn Fast</strong></span></p>
<p class="p1"><span class="s1">Much of great product boils down to the ability for the team to try out lots of ideas quickly. &nbsp;We want to quickly separate the good ideas from the bad. &nbsp;Product discovery is a broad set of techniques intended to help us learn quickly which ideas will fly and which are not so great. &nbsp;Some ideas are big and some are small. &nbsp;Some are risky and some are expensive. &nbsp;Sometimes we need proof, and sometimes we just need evidence. &nbsp;</span></p>
<p class="p1"><span class="s1">Lots of people describe this is different ways. &nbsp;Some like to describe this as &ldquo;fake it before you make it&rdquo; and some like to emphasize the &ldquo;build things that don&rsquo;t scale&rdquo; point. &nbsp;The key is we need to learn fast and minimize waste. &nbsp;</span></p>
<p class="p1"><span class="s1">Using the engineering team to build and release actual products in order to try out an idea is considered the slowest, most expensive way to learn.</span></p>
<p class="p1"><span class="s1"><strong>7. Focus on Key Risks&nbsp;</strong></span></p>
<p class="p1"><span class="s1">There&rsquo;s a couple important points to emphasize about product discovery. &nbsp;</span></p>
<p class="p1"><span class="s1">The first is that we need to focus on the four key risks: &nbsp;value risk &ndash; would anyone buy this or choose to use it?; usability risk &ndash; would they be able to figure out how to use it?; feasibility risk &ndash; can our engineers build this with the technology available, the time available, and the skill-sets available on the team?; and stakeholder risk &ndash; are the different parts of the company ok with this proposed solution?</span></p>
<p class="p1"><span class="s1">In product discovery we are looking for good answers to these four questions. &nbsp;If so, we have the evidence and confidence we need to have the engineering team spend the time to build and deliver a product quality and scale solution.</span></p>
<p class="p1"><span class="s1"><strong>8. The Role of an MVP</strong></span></p>
<p class="p1"><span class="s1">The concept of an MVP is one of the most important concepts in product yet it&rsquo;s also one of the most abused and misunderstood concepts.</span></p>
<p class="p1"><span class="s1">It&rsquo;s always dangerous to generalize, but I&rsquo;m going to go out on a limb here and argue that an MVP should <em>never</em> be a product. &nbsp;In every single case I have ever encountered, when the team spent the time and the money to build an actual QA&rsquo;d product as their MVP, I have always been able to show them afterwards how they could have accomplished the same learning at much less cost and waste. &nbsp;</span></p>
<p class="p1"><span class="s1">So an MVP is an experiment; a test. &nbsp;It&rsquo;s usually one of the forms of prototype. &nbsp;Often that's a user prototype, sometimes it&rsquo;s a live-data prototype, sometimes a feasibility prototype. &nbsp;And sometimes they&rsquo;re hybrids. &nbsp;In every case, it&rsquo;s a fraction of actually building out a real product.</span></p>
<p class="p1"><span class="s1"><strong>9. Product Delivery: Release with Confidence</strong></span></p>
<p class="p1"><span class="s1">My point here is not to tell developers how to build and release software. &nbsp;Actually quite the contrary. &nbsp;One of the issues that comes from the prior issue where teams use the engineering team to create these MVP&rsquo;s, &nbsp;is that the engineering team is often pressured to release software that they know is not really something that should be released. &nbsp;It&rsquo;s not something they feel comfortable standing behind. &nbsp;There might be major reliability issues, or scale issues, or performance problems. &nbsp;But the product manager keeps saying &ldquo;it&rsquo;s just an MVP, so relax!&rdquo;</span></p>
<p class="p1"><span class="s1">I&rsquo;m suggesting here that when it comes to software that your customers are actually depending on to run their business, you should not compromise. &nbsp;We have plenty of good product discovery techniques for testing MVP&rsquo;s in ways that protect our customers, our revenue, our reputation and our own employees.</span></p>
<p class="p1"><span class="s1">So use your best practices, and only release true products to production when you have the necessary confidence in that release. &nbsp;</span></p>
<p class="p1"><span class="s1"><strong>10. <em>Obsess</em> Over Customers</strong></span></p>
<p class="p1"><span class="s1">The final point I&rsquo;d like to make is a bit different. &nbsp;Nearly every company I meet tells me how much they love their customers. &nbsp;It&rsquo;s usually somewhere in their company values or mission statement, but I have to tell you that it&rsquo;s easy to say the words, but much harder to actually follow through. &nbsp;</span></p>
<p class="p1"><span class="s1">I can tell pretty quickly when I talk to the team. &nbsp;If a customer production issue comes up, how do they respond? &nbsp;What level of urgency is there? &nbsp;Does the team reach out directly to customers to understand if they need to? &nbsp;Do team members know customers by name? &nbsp;What type of relationship do they have with customers? &nbsp;Do they consider the customers a big pain, or do they consider them more like colleagues?</span></p>
<p class="p1"><span class="s1">The best way to instill this true empathy for and commitment to customers is to connect the team, including and especially the developers, directly to customers.</span></p>
<p class="p1"><span class="s1">I hope this gives you a better sense of what makes great product teams great. &nbsp;</span></p>Mon, 02 May 2016 10:56:00 -0400http://www.svproduct.com/product-success/Women in Producthttp://www.svproduct.com/women-in-product/
<p class="p1"><span class="s1">Note 1: I&rsquo;m focusing in this article on women, however, my points here are intended to apply to all under-represented groups.</span></p>
<p class="p1"><span class="s1">Note 2: I am highlighting here the product role, which is a subset of the &ldquo;women in tech&rdquo; topic. &nbsp;I would also love to see more women in engineering and design roles, but I am especially focused on the product role because it&rsquo;s such a strong path to CEO and GM roles.</span></p>
<p class="p1"><span class="s1">I still remember the first time I personally witnessed gender-based discrimination in the tech workplace. &nbsp;</span></p>
<p class="p1">I was a young engineering manager at HP, and during one of the quarterly meetings where we&rsquo;d stack rank everyone across the different parts of the organization, there was a discussion comparing the performance of two people, one male and one female. &nbsp;One of the senior managers made the argument that the male should get ranked higher because he had a family to support, the implication being that the female he was being compared to did not. &nbsp;I remember thinking that even if this was something that should be considered, she could very possibly be a single head of household, so that didn&rsquo;t make much sense to me. &nbsp;But I didn&rsquo;t know either person being considered, and I was new to this whole management thing, so regrettably I didn&rsquo;t say anything.</p>
<p class="p1"><span class="s1">Today I rarely see such overt discrimination, at least when it comes to sexism. &nbsp;It still exists; it&rsquo;s just more subtle, and I&rsquo;ve come to believe that much of it today is not intentional. &nbsp;But even though active discrimination may be less prevalent, the legacy it has created persists.</span></p>
<p class="p1"><span class="s1">It hit me recently that it&rsquo;s one thing to&nbsp;<em>not</em>&nbsp;be a sexist or racist, but it&rsquo;s another thing to be actively&nbsp;<em>anti</em>-sexist or&nbsp;<em>anti</em>-racist. &nbsp;</span></p>
<p class="p1"><span class="s1">While I like to believe I&rsquo;m not a sexist or racist, at least not intentionally or consciously, what have I really done to actively combat sexism or racism? &nbsp;</span></p>
<p class="p1"><span class="s1">It&rsquo;s one thing to not intentionally discriminate against women, and it&rsquo;s another to actively work to reverse the legacy of that discrimination.</span></p>
<p class="p1"><span class="s1">I was inspired recently by my friends that put on the <a href="http://www.craft-conf.com/"><span class="s2">Craft Conference</span></a> in Budapest. &nbsp;I consider this one of the best new conferences for software engineers, and last year they had a very visible policy of non-discrimination, but this year they went further and offered &ldquo;diversity scholarships&rdquo; to try to actively increase the representation from under-represented groups. &nbsp;</span></p>
<p class="p1"><span class="s1">To me, that&rsquo;s an example of not just having a policy against discrimination, but proactively working for meaningful change.</span></p>
<p class="p1"><span class="s1">There are many things I think we can all to do to actively work to correct these imbalances and inequities. &nbsp;Here are some examples:</span></p>
<p class="p1"><span class="s1">- When you recruit, don&rsquo;t just prioritize resumes of under-represented groups, but go out and figure out how to increase the pool entering your funnel.</span></p>
<p class="p1"><span class="s1">- Make sure every member of your team is able to contribute from a safe place. &nbsp;If you don&rsquo;t know what I mean by this, check out the recent <a href="http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html"><span class="s2">article</span></a> describing how significant this factor is.</span></p>
<p class="p1"><span class="s1">- If you see harassment or discrimination taking place, call it out &ndash; it diminishes us all.</span></p>
<p class="p1"><span class="s1">For myself, going forward, I&rsquo;m committing to doing more than just not discriminating:</span></p>
<p class="p1"><span class="s1">- I have already begun to actively work to change the image people have in their mind when they picture a strong, smart, hard-working product manager. &nbsp;</span></p>
<p class="p1"><span class="s1">- I&rsquo;m now offering several scholarship spots in my public workshops to try to remove the financial barriers for women and other under-represented groups. &nbsp;</span></p>
<p class="p1"><span class="s1">- Finally, as I encounter these smart and ambitious people, I am going to try to personally make sure they get placed in a good product company working under a proven product leader that can help them reach their potential.&nbsp;</span></p>
<p class="p1">And I&rsquo;ll continue to seek out other ways I can use my platform in the technology community to help.</p>
<p class="p1"><span class="s1"><br /></span></p>Tue, 12 Apr 2016 18:03:00 -0400http://www.svproduct.com/women-in-product/Discovery Coacheshttp://www.svproduct.com/discovery-coaches/
<p class="p1"><span class="s1">In my last article on <a href="http://www.svpg.com/discovery-sprints"><span class="s2">Discovery Sprints</span></a> I mentioned the concept of Discovery Coaches and several people asked me about that, so I thought I&rsquo;d describe more about what this role is and when it&rsquo;s helpful.</span></p>
<p class="p1">For many years, as teams move to Agile methods (they usually start with Scrum), many companies decide to contract with or hire an Agile Coach. These people are there to help the broader team &ndash; especially engineers, QA, product managers and product designers &ndash; to learn the methods and mindset involved in moving to Agile. &nbsp;</p>
<p class="p1"><span class="s1">This sounds straightforward enough, but a while ago I wrote about the problems that arise because the vast majority of these Agile Coaches do not have experience with tech product companies, so their experience is limited to delivery, and they would more accurately be considered Agile <em>Delivery</em> Coaches. &nbsp;They understand the engineering and release side of things, but not the discovery side of things. &nbsp;This articles speaks to <span class="s2"><a href="http://www.svproduct.com/selecting-an-agile-coach/"><span class="s2">how to select an Agile Coach</span></a></span> that understands the needs of modern product organizations.</span></p>
<p class="p1"><span class="s1">So many product companies have experienced this issue that it created the need for coaches that do have deep experience with product companies and the key product roles, especially product management and user experience design, and these people are often called <em>Discovery Coaches. &nbsp;</em></span></p>
<p class="p1"><span class="s1">Discovery Coaches are typically former product managers or product designers (or former leaders of these areas) and they have usually worked for, or with, leading product companies. &nbsp;So they are able to work side-by-side with actual product managers and designers, and not just recite Agile platitudes, but actually show the team how to work effectively.</span></p>
<p class="p1"><span class="s1">Every Discovery Coach has their preferred way of engaging with a team, but usually they are with you for a week or so at a time, with one or a small number of product teams, and they help you through one or more discovery cycles of ideation, creating an MVP experiment (usually a form of prototype), validating that prototype with customers to gauge their reactions; engineers to evaluate feasibility; and stakeholders to assess whether this solution would work for your business.</span></p>
<p class="p1"><span class="s1">It&rsquo;s hard for me to imagine an effective Discovery Coach that didn&rsquo;t have first-hand experience as a product manager or designer at a modern product company. &nbsp;That&rsquo;s likely one of the main reasons there&rsquo;s a shortage of these Discovery Coaches. &nbsp;It&rsquo;s also important that the Discovery Coach understand how to include engineering in the mix, being sensitive to their time, but understanding the essential role they play in innovation.</span></p>
<p class="p1"><span class="s1">Discovery Coaches are not unlike Lean Startup Coaches. &nbsp;The main difference is that Lean Startup Coaches often focus on helping a team to discover not only their product, but also their business model, and their sales and marketing strategy. &nbsp;Once the new business has some traction, the discovery is usually more about continuously improving an existing product in substantial ways rather than creating an all new business. &nbsp;Because of this difference, many Lean Startup Coaches don&rsquo;t actually have the necessary product experience. &nbsp;Although my view is that product discovery is the most important competency of a new startup, so to me an effective Lean Startup Coaches must also be very strong at product (see&nbsp;<span class="s3"><a href="http://www.svproduct.com/the-biggest-risk/"><span class="s3">www.svpg.com/the-biggest-risk</span></a></span>).</span></p>
<p class="p1">I know several very strong Discovery Coaches and I&rsquo;m happy to provide introductions. &nbsp;Unfortunately, they are usually booked up, so I am continuously seeking out more of them. &nbsp;If you have strong product and/or design experience from a strong product company using modern practices, and are helping product teams as a Discovery Coach, feel free to reach out to me to let me know who you are, where you&rsquo;re based, and what types of companies you prefer to work with.</p>
<p class="p1"><span class="s1"><br /></span></p>Thu, 10 Mar 2016 17:45:00 -0500http://www.svproduct.com/discovery-coaches/Discovery Sprintshttp://www.svproduct.com/discovery-sprints/
<p class="p1"><span class="s1">I find that many teams, especially those new to modern product techniques, are looking for a structured introduction to modern product discovery. &nbsp;In this article, I&rsquo;d like to describe the concept of a <em>discovery sprint</em>, and also introduce you to a new book that goes into depth on this technique.</span></p>
<p class="p1"><span class="s1">A <em>discovery sprint</em> is a one week <span class="s2"><a href="http://www.svproduct.com/time-boxing-product-discovery/"><span class="s2">time-box of product discovery work</span></a></span>, designed to tackle at least one substantial problem or risk in your product's definition.</span></p>
<p class="p1">Some people use the term <em>design sprint </em>for this, but as the purpose of the work, when done well, goes significantly beyond design, I prefer the more general term. &nbsp;This is also a good example of a product team working in what&rsquo;s known as <em>Dual-Track Agile</em>, or <em>Continuous Discovery and Delivery</em>. &nbsp;Further, if your company has been struggling with the concept of MVP, this is a very good way to start getting the value from this key technique.</p>
<p class="p1"><span class="s1">I first met the <a href="http://www.gv.com/team/">Google Ventures</a>&nbsp;team many years ago when they were getting started. &nbsp;They are part of Google&rsquo;s investment arm, but even more valuable to the startup than their money, GV created a small team to actually go in and help the companies they invest in to get their product efforts off to a good start. &nbsp;Their model is that they typically spend a week with the startup, rolling their sleeves up, and showing them how to do product discovery by doing it with them side-by-side.</span></p>
<p class="p1"><span class="s1">I also know several other proven product people that are known as <em>discovery coaches</em>, that do essentially the same thing for the teams they are helping.</span></p>
<p class="p1"><span class="s1">In any case, during this week of intense discovery work, you and your team will likely explore dozens of different product ideas, but you&rsquo;re always trying to solve some substantial business problem, and you&rsquo;re always ending your week by validating your potential solution with real users and customers. &nbsp;And in my experience, the result is consistently big learning and insights. &nbsp;The type of learning that can change the course of your product or your company.</span></p>
<p class="p1"><span class="s1">Within this general framework, different discovery coaches have different specific methods they advocate for helping the team though the process to get big learning in just these five days.</span></p>
<p class="p1"><span class="s1">After working with more than 100 startups, and refining their methods as they learned what worked well and what didn&rsquo;t, the GV team decided to share their learnings in a new book, <a href="http://www.amazon.com/Sprint-Solve-Problems-Test-Ideas/dp/150112174X"><span class="s2"><em>Sprint: How To Solve Big Problems and Test New Ideas In Just Five Days</em></span></a> by Jake Knapp, John Zeratsky and Braden Kowitz. &nbsp;I was invited to review the upcoming book and I found it one of the best new books on product I've seen in a long time.&nbsp;</span></p>
<p class="p1"><span class="s1">The authors lay out a week that begins by mapping the problem space, picking the problem to be solved and the target customer, and then progresses into pursuing several different approaches to the solution, and then narrowing down and fleshing out the different potential solutions, then creating a high-fidelity (realistic looking and feeling) prototype, and finally putting that prototype in front of actual target users and observing their reactions. &nbsp;And yes, you can absolutely do this all in a week.</span></p>
<p class="p1"><span class="s1">The book spells out the GV team's favorite techniques to do each of these steps. &nbsp;If you&rsquo;ve been reading these articles, you&rsquo;ll recognize most of the individual techniques, but what I like so much about this book is that when teams are getting started they often crave the structure of a proven, step-by-step recipe, and this book spells this out over nearly 300 pages, with dozens of examples from great products and teams you&rsquo;ll recognize.</span></p>
<p class="p1"><span class="s1">There are several situations where I recommend a discovery sprint. &nbsp;One is when the team is struggling to learn how to do product discovery. &nbsp;Another is when they have something big and critically important and/or difficult to tackle. &nbsp;Another is when things are just moving too slow. &nbsp;If your team is experiencing any of these, I hope you&rsquo;ll get the book and give the method a try.</span></p>Mon, 29 Feb 2016 14:12:00 -0500http://www.svproduct.com/discovery-sprints/When Performance Is Measured By Resultshttp://www.svproduct.com/when-performance-is-measured-by-results/
<p class="p1"><span class="s1">NOTE: I was invited to write the foreword for Christina Wodke&rsquo;s new book on OKR&rsquo;s, <a href="http://www.amazon.com/Radical-Focus-Christina-Wodtke-ebook/dp/B01BFKJA0Y"><span class="s2"><em>Radical Focus</em></span></a>, and I am sharing the foreword here.</span></p>
<p class="p1"><span class="s1">I was extremely fortunate to have started my career at Hewlett-Packard as an engineer during their heyday, when they were known as the industry&rsquo;s most successful and enduring example of consistent innovation and execution. &nbsp;As part of HP&rsquo;s internal engineering management training program called &ldquo;The HP Way," I was introduced to a performance management system known as &ldquo;MBO&rdquo; - Management by Objectives.</span></p>
<p class="p1">The concept was straight-forward, and based on two fundamental principles. &nbsp;The first can easily be summed up with the famous General George Patton quote: "Don't tell people how to do things, tell them what you need done and let them surprise you with their results.&rdquo; &nbsp;The second was captured by HP&rsquo;s tagline of that era,&nbsp;&ldquo;When Performance Is Measured By Results.&rdquo; &nbsp;The idea here is that you can release all the features you want, but if it doesn&rsquo;t solve the underlying business problem, you haven&rsquo;t really solved anything.</p>
<p class="p1"><span class="s3">The first principle is really about how to motivate people to get them to do their best work, and the second is all about how to meaningfully measure progress.</span></p>
<p class="p1"><span class="s3">So much has changed since my time at HP. &nbsp;The technologies are dramatically more advanced, the scale and scope of systems we build is several orders of magnitude larger, teams move much faster, generally with superior quality and performance, all delivered at a fraction of the cost. &nbsp;However, these two performance management principles are still at the foundation of how the best companies and teams operate.</span></p>
<p class="p1"><span class="s3">The MBO system was refined and improved at several companies over the years, most notably Intel, and today the primary performance management system we use is known as the &ldquo;OKR&rdquo; system - Objectives and Key Results.</span></p>
<p class="p1"><span class="s1">Unfortunately, another thing that hasn&rsquo;t changed is that most teams still don&rsquo;t operate with these principles. &nbsp;</span></p>
<p class="p1"><span class="s1">Instead, groups of executives and other stakeholders all too often come up with the quarterly &ldquo;roadmap&rdquo; of features and projects and then pass them down to the product teams, essentially telling them how to solve the underlying business problems. &nbsp;The teams are just there to flesh out the details, code and test, with little understanding of the bigger context, and even less belief that these are in fact the right solutions. &nbsp;Teams today are all too often feature factories, with little regard for whether or not the features actually solve the underlying business problems. &nbsp;Progress is measured by output and not outcome.</span></p>
<p class="p1"><span class="s1">Christina&rsquo;s book is intended to help any organization start operating like the best organizations. &nbsp;I have seen these techniques deployed successfully in organizations as large as a 60,000 employee company to as small as a 3-person startup. &nbsp;Large or small, if you&rsquo;ve worked hard to hire smart people, this system will help you unleash their potential.</span></p>
<p>Christina&rsquo;s book is now available&nbsp;on <a href="http://www.amazon.com/Radical-Focus-Christina-Wodtke-ebook/dp/B01BFKJA0Y"><span class="s2">Amazon</span></a>.</p>
<p class="p1"><span class="s1"><br /></span></p>Mon, 08 Feb 2016 12:11:00 -0500http://www.svproduct.com/when-performance-is-measured-by-results/Devolving From Good To Badhttp://www.svproduct.com/devolving-from-good-to-bad/
<p class="p1"><span class="s1">Lots of people have written about the challenges of managing growth. &nbsp;Especially about the importance of working hard to maintain staff quality as you scale the organization. &nbsp;There is little question that most organizations become worse in their ability to rapidly deliver consistent innovation as they grow, yet most people attribute this to staff quality and also process and communication issues of scale. &nbsp;Some believe that this is unavoidable. &nbsp;</span></p>
<p class="p1"><span class="s1">I normally write about how to evolve your organization from a weak product org to a strong one. &nbsp;But in this article I want to talk about a pattern that I see in many companies that are actually doing really well, growing aggressively, yet they will sometimes, over time and unintentionally, replace their good behaviors with bad ones. &nbsp;</span></p>
<p class="p1"><span class="s1">I have never seen this anti-pattern written about before, and I suspect it&rsquo;s going to make more than a few people uncomfortable, but it&rsquo;s a serious issue that I think needs to be out in the open, as it&rsquo;s not hard to prevent if you&rsquo;re aware.</span></p>
<p class="p1"><span class="s1">The scenario is that you are probably a later stage startup or growth stage company. &nbsp;You&rsquo;ve probably achieved product/market fit, at least for an initial product, and to have accomplished that, you&rsquo;ve probably done some important things right. But then you get some serious funding, or some board member strongly suggests that you need to bring on some &ldquo;adult supervision,&rdquo; or some experienced people from brand-name companies. &nbsp;</span></p>
<p class="p1"><span class="s1">Here&rsquo;s the thing, the new people you hire are often from those large, brand-name companies that have stopped growing, are often companies that have long since lost their ability to innovate, and have been living off their brand for many years. Because of this, they&rsquo;re not on the trajectory they once were, and people leave.</span></p>
<p class="p1"><span class="s1">No real problem so far. &nbsp;Would you rather hire all your staff and leaders from Google, Facebook, Amazon and Apple? Sure, but these people are in very short supply and there is definitely lots of strong talent at other companies. &nbsp;</span></p>
<p class="p1"><span class="s1">Here&rsquo;s the problem. &nbsp;Let&rsquo;s say you are at a young, growth stage company, and you decide to hire a senior leader, maybe the head of product, or the head of engineering, or head of marketing, from a brand name like Oracle. &nbsp;The board will probably like that. The issue is that unless you make this clear at the outset, that new leader may assume you&rsquo;re hiring them for their knowledge of process and how to define and deliver products. And so they bring with them their views on how things should work. Even worse, they often then proceed to hire people that want to work in those ways.</span></p>
<p class="p1"><span class="s1">Note that&nbsp;</span>I&rsquo;m picking on Oracle here as an example but they are certainly not the only one &ndash; there are actually a great many very strong people to hire from Oracle as they love to acquire companies, often very good companies, but those strong product, design and technology people they acquired rarely like Oracle's ways of working.</p>
<p class="p1"><span class="s1">A lot of people assume that companies slow down and lose their mojo as a direct result of hiring more people. &nbsp;It&rsquo;s true that larger organizations bring their own challenges, but the issue is not the number of people, it&rsquo;s the culture of the company, it&rsquo;s how these people work, and the skills and behaviors of their leaders. &nbsp;As I&rsquo;ve pointed out in recent articles, some of the best (fastest and most consistently innovative) product companies in the world are actually very large.&nbsp;</span></p>
<p class="p1"><span class="s1">I have seen this anti-pattern play out at every level of a company, from individual software developers all the way to CEO. It doesn&rsquo;t happen overnight; it happens over years. &nbsp;But I&rsquo;ve seen it enough I&rsquo;m convinced it&rsquo;s an anti-pattern. Many people intuitively sense this problem but they usually just attribute it to "a big company person" but this is less about being from a big company and more about being from a company that's not strong at product.</span></p>
<p class="p1"><span class="s1">I know of two ways to prevent this problem from infecting your company:</span></p>
<p class="p1"><span class="s1">The first is to have a very strong and very <em>intentional</em> product culture, and to have that culture very well established so that new hires know they&rsquo;re joining a different type of company that takes pride in how they work and using best practices. When you join Netflix, or Airbnb, or Facebook, it&rsquo;s something you figure out in your first days, and that&rsquo;s by design.</span></p>
<p class="p1"><span class="s1">The second way of preventing this is to make this explicit in the interview and on-boarding process. As part of my advisory work, I&rsquo;m often on the interview team for senior positions, and when the person is coming from one of these types of companies, I'm really up front with the prospective hire, and we&rsquo;ll talk about the reasons why their former company has not produced successful new products in many years, and I&rsquo;ll emphasize to them that the new company is interested in them because of their mind and their talents, and of course they wouldn&rsquo;t want to bring with them the bad practices of their former company.</span></p>
<p class="p1">In my experience, people are really good about this when you talk openly and honestly about it. &nbsp;In fact, people often tell me it&rsquo;s a major reason why they want to leave their former company. &nbsp;It&rsquo;s more about getting this to be something you and they are very aware of. &nbsp;Keep in mind that people often revert to past behaviors when things get stressful.</p>
<p class="p1"><span class="s1"><br /></span></p>Mon, 11 Jan 2016 12:41:00 -0500http://www.svproduct.com/devolving-from-good-to-bad/Product For Legacy Companieshttp://www.svproduct.com/product-for-legacy-companies/
<p class="p1"><span class="s1">NOTE: This article is from the foreword to the new 2nd Edition of <a href="http://www.amazon.com/Art-Scalability-Architecture-Organizations-Enterprise/dp/0134032802"><span class="s2">The Art of Scalability</span></a> by Marty Abbott and Michael Fisher. &nbsp;I&rsquo;m reprinting it here because quite a few people have written me asking how to get their old-style company to start behaving more like a modern technology-powered business.</span></p>
<p class="p1"><span class="s1">Perhaps your company began as a brick-and-mortar retailer, or an airline, or a financial services company.</span></p>
<p class="p1"><span class="s1">A retailer creates (or buys) technology to coordinate and manage inventory, distribution, billing, and point of sale systems. An airline creates technology to manage the logistics involved in flights, crews, reservations, payment, and fleet maintenance. A financial services company creates technology to manage its customers&rsquo; assets and investments.</span></p>
<p class="p1">But over the past several years, almost all of these companies, as well as their counterparts in nearly every other industry, have realized that to remain competitive, they need to take their use of technology to an entirely different level&mdash;they now need to engage directly with their customers.</p>
<p class="p1"><span class="s1">Every industry is being reshaped by technology. &nbsp;If they hope to maintain their place as competitive, viable enterprises, companies have no choice but to embrace technology, often in ways that go well beyond their comfort zone.</span></p>
<p class="p1"><span class="s1">For example, most retailers now find they need to sell their goods directly to consumers online. &nbsp;Most airlines are trying very hard to entice their customers to purchase their air travel online directly through the airline&rsquo;s site. &nbsp;And nearly all financial services companies work to enable their customers to manage assets and trade directly via their real-time financial sites.</span></p>
<p class="p1"><span class="s1">Unfortunately, many of these companies are trying to manage this new customer-facing and customer-enabling technology in the same way they manage their internal technology. The result is that many of these companies have very broken technology and provide terrible customer experiences. Even worse, they don&rsquo;t have the organization, people, or processes in place to improve them.</span></p>
<p class="p1"><span class="s1">What companies worldwide are discovering is that there is a very profound difference between utilizing technology to help <em>run </em>your company, and leveraging technology to provide your actual products and services directly <em>for </em>your customers. It also explains why &ldquo;technology transformation&rdquo; initiatives are popping up at so many legacy companies.</span></p>
<p class="p1"><span class="s1">This book is all about this necessary transformation. Such a transformation represents a shift in organization, people, process, and especially culture, and scalability is at the center of this transformation:</span></p>
<ul class="ul1">
<li class="li1"><span class="s1">Scaling from hundreds of your employees using your technology, to millions of your customers depending on your technology</span></li>
<li class="li1"><span class="s1">Scaling from a small IT cost-center team serving their colleagues in finance and marketing, to a substantial profit-center technology team serving your customers</span></li>
<li class="li1"><span class="s1">More generally, scaling your people, processes, and technology to meet the demands of a modern technology-powered business</span></li>
</ul>
<p class="p1"><span class="s1">But why is technology for your customers so different, and so much more difficult to manage, than technology for your employees? &nbsp; Several reasons:</span></p>
<ul class="ul1">
<li class="li1"><span class="s1">You pay your employees to work at your company and use the technology you tell them they need to use. &nbsp;In contrast, every customer makes his or her own purchase decision&mdash;and if she doesn&rsquo;t want it, she won&rsquo;t use it. &nbsp;Your customers must <em>choose </em>to use your technology.&nbsp;</span></li>
<li class="li1"><span class="s1">With your own employees, you can get away with requiring training courses, reading manuals, or holding their hands if necessary. In contrast, if your customers can&rsquo;t figure out how to use your technology, they are just a click away from your competitor.&nbsp;</span></li>
<li class="li1"><span class="s1">For internal technology, we measure scale and simultaneous usage in the hundreds of users. For our customers, that scope increases to hundreds of thousands or very often millions of users.&nbsp;</span></li>
<li class="li1"><span class="s1">With internal technology, if a problem arises with the technology, the users are your employees and they are forced to deal with it. For your customers, an issue such as an outage immediately disrupts revenue streams, usually gets the attention of the CEO, and sometimes even draws the notice of the press.&nbsp;</span></li>
</ul>
<p class="p1"><span class="s1">The harsh truth is that most customer technology simply has a dramatically higher bar set in terms of the definition, design, implementation, testing, deployment, and support than is necessary with most internal technology.</span></p>
<p class="p1"><span class="s1">For most companies, establishing a true customer technology competency is <em>the single most important thing for them to be doing to ensure their survival</em>, yet remarkably some of them don&rsquo;t even realize they have a problem. They assume that &ldquo;technology is technology&rdquo; and the same people who managed their enterprise resource planning implementation shouldn&rsquo;t have too much trouble getting something going online.</span></p>
<p class="p1"><span class="s1">If your company is in need of this transformation, then this book is essential reading. It provides a proven blueprint for the necessary change.</span></p>
<p class="p1">Marty and Michael have been there and done that with most of the technology industry&rsquo;s leading companies. I have known and worked with both of these guys for many years. They are not management consultants who could barely launch a&nbsp;brochure site. They are hands-on leaders who have spent decades in the trenches with their teams creating technology-powered businesses serving hundreds of millions of users and customers. They are the best in the world at what they do, and this new edition is a goldmine of information for any technology organization working to raise its game.&nbsp;</p>
<p class="p1"><span class="s1"><br /></span></p>Tue, 29 Dec 2015 13:06:00 -0500http://www.svproduct.com/product-for-legacy-companies/Missionaries vs. Mercenarieshttp://www.svproduct.com/missionaries-vs-mercenaries/
<p class="p1"><span class="s1">One of my all-time favorite quotes in our industry comes by way of the legendary VC, <a href="https://en.wikipedia.org/wiki/John_Doerr"><span class="s2">John Doerr</span></a>, where he argues that "we need teams of missionaries, not teams of mercenaries.&rdquo; This point captures so much, and gets right to the heart of the most important trait of strong leaders, strong organizations, and strong product teams.</span></p>
<p class="p1">This is not hard to spot, either way. &nbsp;Teams of missionaries are engaged, motivated, have a deep understanding of the business context, and tangible empathy for the customer. Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.</p>
<p class="p1"><span class="s1">In my experience with product teams, there&rsquo;s simply no comparison between the morale, speed and most importantly, the results, of a team of&nbsp;</span>missionaries&nbsp;<span class="s1">as compared with a team of&nbsp;</span>mercenaries.&nbsp;</p>
<p class="p1"><span class="s1">So why don't more companies get this? &nbsp;There are typically three main reasons I see:</span></p>
<p class="p1"><span class="s1">1. Leadership. &nbsp;So many executives and stakeholders think they know the answers, and they really don&rsquo;t even want to discuss or debate it. &nbsp;They just want a team that will follow their directions. &nbsp;These same leaders usually complain to me that the team moves too slowly, and that unless they spell out every little detail the team gets it wrong, and in any case they rarely blame themselves for the poor results.</span></p>
<p class="p1"><span class="s1">2. Staffing. &nbsp;Some leaders absolutely get the importance of a team of missionaries, but they have inherited an organization that is staffed by people that are resigned to the mercenary model. &nbsp;A variation of this is when the organization has significant outsourcing of the designers or engineers that are on the teams. &nbsp;It&rsquo;s nearly impossible to have a team of missionaries when your engineers work for another company and are under contract to build what you tell them to. &nbsp;That&rsquo;s pretty much the definition of a mercenary. &nbsp;And it leads to <a href="http://www.svpg.com/epic-waste"><span class="s2">epic waste</span></a>.</span></p>
<p class="p1"><span class="s1">3. Process. &nbsp;Several product development processes out there, especially those that claim to be designed for &ldquo;the enterprise," are predicated on the mercenary model. &nbsp;Now none of them would ever describe themselves that way, but that&rsquo;s very much what I argue is going on. &nbsp;For example, a few people have asked me about&nbsp;<a href="http://www.scaledagileframework.com/"><span class="s2">SAFe</span></a> (Scaled Agile Framework). &nbsp;I always tell them that what I know of SAFe is all second-hand because I literally don&rsquo;t know of a single strong product company that uses it. &nbsp;But from everything I have heard and read about it, I have a hard time imagining a worse model for true, technology-powered product companies that depend on a stream of consistent innovation. &nbsp;In contrast, the Spotify model of scaling Agile is much more in line with what I advocate, and I would argue theirs is predicated on the missionary model. &nbsp;More on this topic in upcoming articles.</span></p>
<p class="p1"><span class="s1">The three issues above are not mutually exclusive. &nbsp;In fact, over time one usually leads to the others. &nbsp;And when the objective is to transform an organization to best practices, these are among the most critical yet toughest parts of that transition.</span></p>
<p class="p1"><span class="s1">So how do you change?</span></p>
<p class="p1"><span class="s1">It begins with those same three areas:</span></p>
<p class="p1"><span class="s1">First, we need to <a href="http://www.svpg.com/product-fail"><span class="s2">educate</span></a> the leadership team. &nbsp;</span></p>
<p class="p1"><span class="s1">Second, we need to raise the bar on the staff &ndash; starting with product managers but also product designers and at least the senior engineers / tech leads. &nbsp;If the company isn&rsquo;t set up this way already, then it&rsquo;s critical to move aggressively to durable, cross-functional, co-located (whenever possible) product teams (&ldquo;squads" in Spotify lingo). &nbsp;</span></p>
<p class="p1"><span class="s1">Finally, it&rsquo;s about adopting the processes and techniques that allow teams to show what they can do. &nbsp;There&rsquo;s quite a bit here but it starts with a compelling product vision combined with business outcomes (objectives with measurable key results) for the organization and for each product team.</span></p>
<p class="p1">If your organization is acting a lot more like teams of mercenaries rather than missionaries, then I hope you&rsquo;ll consider seriously why this might be the case, and whether your organization has the capacity and the will to turn this around.</p>
<p class="p1"><span class="s1"><br /></span></p>Tue, 24 Nov 2015 12:15:00 -0500http://www.svproduct.com/missionaries-vs-mercenaries/Innovation vs. Executionhttp://www.svproduct.com/innovation-vs-execution/
<p class="p1"><span class="s1">In my last <span class="s2"><a href="http://www.svproduct.com/discovery-vs-delivery/"><span class="s2">article</span></a></span>&nbsp;I discussed how we need to simultaneously learn fast in product discovery, yet still release with confidence in product delivery. I got a very good response from this article, as well as many questions as to how teams can get better at one or both. &nbsp;This quickly gets into a very deep discussion of culture. &nbsp;You can think of this as the characteristics of a strong innovation culture, versus those of a strong execution culture.</span></p>
<p class="p1"><span class="s1">In this article&nbsp;I wanted to say a bit more about how your company's culture either helps or hinders innovation or execution, and then&nbsp;I&rsquo;d like to give you some pretty deep questions for your team to consider.</span></p>
<p class="p1"><span class="s1">What does it really mean to have a strong&nbsp;<em>innovation culture</em>?</span></p>
<ol class="ol1">
<li class="li1"><span class="s1">Culture of&nbsp;<em>experimentation</em>&nbsp;- teams know they can run tests, and some will succeed and many will fail, and this is acceptable and understood</span></li>
<li class="li1"><span class="s1">Culture of&nbsp;<em>open minds</em>&nbsp;&ndash; teams know that good ideas can come from anywhere, and aren&rsquo;t always obvious at the outset</span></li>
<li class="li1"><span class="s1">Culture of&nbsp;<em>empowerment</em>&nbsp;- individuals and teams feel empowered to be able to try out an idea</span></li>
<li class="li1"><span class="s1">Culture of&nbsp;<em>technology</em>&nbsp;- teams realize that true innovation can be inspired by new technology and analysis of data, as well as by customers</span></li>
<li class="li1"><span class="s1">Culture of&nbsp;<em>business and customer savvy teams</em>&nbsp;- teams, including developers, have a deep understanding of the business needs and constraints, and understanding of (and access to) the users and customers</span></li>
<li class="li1"><span class="s1">Culture of&nbsp;<em>skillset</em>&nbsp;<em>diversity</em>&nbsp;- teams appreciate that different skills contribute to innovative solutions &ndash; especially engineering, UX design and product</span></li>
<li class="li1"><span class="s1">Culture of&nbsp;<em>discovery techniques&nbsp;</em>- the mechanisms are in place for ideas to be tested out quickly and safely (protecting brand, revenue, customers and colleagues)</span></li>
</ol>
<p class="p1"><span class="s1">What does it really mean to have a strong&nbsp;<em>execution culture</em>?</span></p>
<ol class="ol1">
<li class="li1"><span class="s1">Culture of <em>urgency</em> &ndash; people feel like they are in war-time and that if they don&rsquo;t find a way to move fast then bad things could happen</span></li>
<li class="li1"><span class="s1">Culture of <em>high-integrity commitments</em> &ndash; teams understand the need for (and power of) commitments, but they also insist on <a href="http://www.svproduct.com/managing-commitments-in-an-agile-team/">high-integrity commitments</a></span></li>
<li class="li1"><span class="s1">Culture of <em>empowerment</em> &ndash; teams feel like they have the tools, resources and the permission to do whatever is necessary to meet their commitments</span></li>
<li class="li1"><span class="s1">Culture of <em>accountability</em> &ndash; one way or another people and teams feel a deep responsibility to meet their commitments; accountability also implies consequences &ndash; not necessarily being terminated except in extreme and repeated situations &ndash; more likely consequences to their reputations among their peers</span></li>
<li class="li1"><span class="s1">Culture of <em>collaboration</em> &ndash; while team autonomy and empowerment is important, teams understand their even higher need to work together to accomplish many of the biggest and most meaningful objectives</span></li>
<li class="li1"><span class="s1">Culture of&nbsp;<em>results</em>&nbsp;&ndash; is the focus on output or is the focus on results?</span></li>
<li class="li1"><span class="s1">Culture of <em>recognition</em> &ndash; teams often take their cues from what is rewarded and what is accepted. &nbsp;Is it just the team that comes up with the great new idea that gets rewarded, or the team that delivered on a brutally tough commitment? &nbsp;And what is the message if missing a commitment is seen as easily excusable?</span></li>
</ol>
<p class="p1"><span class="s1">So if these characteristics help define each culture, this begs some pretty tough questions:</span></p>
<ul class="ul1">
<li class="li1"><span class="s1">Is an innovation culture in any way inherently at odds with an execution culture?</span></li>
<li class="li1"><span class="s1">Does a strong execution culture lead to a stressful (or worse) work environment?</span></li>
<li class="li1"><span class="s1">What types of people, including leaders, are attracted to, and needed, for each type of culture?</span></li>
</ul>
<p class="p1"><span class="s1">I can tell you that there do exist companies that are very strong at both consistent innovation and execution. &nbsp;Amazon is one of the best examples. &nbsp;However, it&rsquo;s also pretty well known that the Amazon work environment is not for the faint of heart. &nbsp;I&rsquo;ve found that most companies that are exceptionally strong at execution are pretty tough places to work. &nbsp;</span></p>
<p class="p1"><span class="s1">In my experience working with companies, only a few companies are strong at both innovation and execution; many are good at execution but weak at innovation; some are strong at innovation and just okay at execution; and a depressing number of companies are poor at both innovation and execution (usually older companies that have lost their product mojo a long time ago but still have a strong brand and customer base to lean on).</span></p>
<p class="p2">In any case, what I hope you and your team will consider doing is assess yourself along these dimensions of innovation and execution, and then ask yourselves where you would like to be, or think you need to be, as a team or company? &nbsp; The techniques for strong innovation and strong execution exist and are well understood at leading companies, but&nbsp;in my experience the hard part is in being <em>willing</em> to actually do the things that change the culture.</p>Tue, 10 Nov 2015 22:31:00 -0500http://www.svproduct.com/innovation-vs-execution/Discovery vs. Deliveryhttp://www.svproduct.com/discovery-vs-delivery/
<p class="p1"><span class="s1">Most of us are working on solving some pretty hard problems, and it usually ends up taking some fairly complex systems in order to power these solutions. &nbsp;As such, for most teams there are two very significant challenges to tackle:</span></p>
<p class="p1"><span class="s1">First,&nbsp;<em>discovering</em>, in detail, what the customer solution needs to be. &nbsp;That includes everything from making sure there&rsquo;s enough customers that even need this solution (the demand) and then coming up with a solution that works for our customers and our own company. &nbsp;Even harder, we need to make sure we come up with a <em>single</em> solution that works for many customers, and not a series of specials. &nbsp;In order to do this, we need to <em>learn fast.</em></span></p>
<p class="p1"><span class="s1">Second, we need to ensure we&nbsp;<em>deliver</em>&nbsp;a robust and scalable implementation that our customers can depend on for consistently reliable value. Your team needs to be able to <em>release with confidence</em>. &nbsp;While we never have 100% confidence, you should not have to &ldquo;release and pray."</span></p>
<p class="p1"><span class="s1">So we need to simultaneously learn fast and also release with confidence.</span></p>
<p class="p1"><span class="s1">It&rsquo;s understandable that many teams might naturally view these two difficult goals as at odds with each other. &nbsp;We are in a big hurry to push something out there in order to learn what works and what doesn&rsquo;t; yet we don&rsquo;t want to release something that&rsquo;s not ready for prime time, and risk hurting our customers and damaging our brand.</span></p>
<p class="p1"><span class="s1">I spend a lot of my time visiting with product teams, and I have on occasion been called out for pushing hard one minute for the team to be much more aggressive in getting out to customers and getting early feedback on their ideas, and then just minutes later pushing that same team hard not to compromise their standards on releasing scalable, fault-tolerant, reliable, high-performance, secure software. &nbsp;</span></p>
<p class="p1"><span class="s1">You might also recognize this problem in another guise. &nbsp;Many teams get into a lot of grief with the concept of a Minimal Viable Product (MVP) because on the one hand we are very motivated to get this out in front of customers fast to get feedback and learn, and on the other hand when we do get out there fast, people feel like this so-called &ldquo;product&rdquo; is an embarrassment to the brand and the company, and how could we possibly consider &ldquo;launching&rdquo; this?</span></p>
<p class="p1"><span class="s1">In this article I want to clarify how strong teams work in order to meet these dual and simultaneous objectives of rapid learning in discovery, yet delivering stable and solid releases.</span></p>
<p class="p1"><span class="s1">In general I find that most product teams have a much better sense of how to accomplish the second goal of delivering solid software, than how to accomplish the first goal of rapid experimentation and discovery. &nbsp;Continuous delivery is a good example of an advanced delivery technique that I find in teams that understand the importance of a series of small, incremental changes to a complex system.</span></p>
<p class="p1"><span class="s1">Part of what causes confusion is a dilution of what is really meant when we call something a &ldquo;product&rdquo; or &ldquo;product-quality&rdquo; or &ldquo;productized&rdquo; or &ldquo;live in production." &nbsp;I always try hard to reserve this use of the product term to describe the state where we can actually run a business on this. &nbsp;Specifically, it is scalable and performant to the degree necessary. &nbsp;It has a strong suite of regression tests. &nbsp;It is instrumented to collect the necessary analytics. &nbsp;It has been internationalized and localized where appropriate. &nbsp;It&rsquo;s maintainable. &nbsp;It is consistent with the brand promise. &nbsp;And most importantly it is something the team can <em>release with confidence</em>. &nbsp;</span></p>
<p class="p1"><span class="s1">This is not easy. &nbsp;It&rsquo;s where most of the time goes when our engineers are building. &nbsp;As such, we try very hard not to <em>waste</em> this effort.</span></p>
<p class="p1"><span class="s1">Doing all this work when the product manager isn&rsquo;t even sure this is the solution the customer wants or needs is a recipe for big waste.</span></p>
<p class="p1"><span class="s1">So the purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build production-quality software, it won&rsquo;t be a wasted effort.</span></p>
<p class="p1"><span class="s1">And this is why we have so many different techniques in product discovery. &nbsp;We&rsquo;ve got techniques for getting much deeper understanding of our users and customers, and for validating product ideas both qualitatively and quantitatively. &nbsp;And in fact the majority of the techniques don&rsquo;t even require the developer&rsquo;s time (which is important because we appreciate how much time and effort needs to go into creating production quality software).</span></p>
<p class="p1"><span class="s1">Much of the key to effective product discovery is getting access to our customers without trying to just push our quick experiments into production.</span></p>
<p class="p1"><span class="s1">If you are an early stage startup and you have no customers, then of course this is not really an issue (and it may be premature to even be creating production-quality software).</span></p>
<p class="p1"><span class="s1">But for most of us, we have real customers and real revenue so we do have to care about this. &nbsp;I wrote about many of the most important techniques to do this rapid experimentation in a responsible way in <span class="s2"><a href="http://www.svproduct.com/product-discovery-in-established-companies/"><span class="s2">Product Discovery in Established Companies</span></a></span>.</span></p>
<p class="p1"><span class="s1">Many of our techniques boil down to inviting a set of our customers or prospective customers to &ldquo;opt-in&rdquo; (in one form or another) to test our new product ideas. &nbsp;A customer development program is a great vehicle for this. &nbsp;These people have essentially volunteered to be willing test subjects. &nbsp;We might spend some time talking to them in person and observing them trying out our product ideas, or we might let them run our experimental versions (usually a live-data prototype) for a while and then look at the data they generate.</span></p>
<p class="p1"><span class="s1">But here&rsquo;s the key. &nbsp;If you want to&nbsp;<em>discover</em>&nbsp;great products, it really is essential that you get your ideas in front of real users and customers early and often. &nbsp;If you want to&nbsp;<em>deliver</em>&nbsp;great products, you want to use best practices for engineering, and not try to override the engineer&rsquo;s concerns. &nbsp;</span></p>
<p class="p1">If we want to move fast and discover quickly, we use discovery techniques and opt-in customers. &nbsp;Once we have collected some evidence that we know the solution we need to build, we allow our engineers to build the &ldquo;production-quality&rdquo; software as they see fit to the point where they can release with confidence.</p>
<p class="p1"><span class="s1"><br /></span></p>Thu, 22 Oct 2015 21:18:00 -0400http://www.svproduct.com/discovery-vs-delivery/