{"id":1975,"date":"2017-01-07T20:53:06","date_gmt":"2017-01-07T12:53:06","guid":{"rendered":"http:\/\/www.yibo.net\/?p=1975"},"modified":"2017-01-19T08:52:46","modified_gmt":"2017-01-19T00:52:46","slug":"successful-product-team-ten-important-characteristics","status":"publish","type":"post","link":"https:\/\/www.yibo.net\/?p=1975","title":{"rendered":"A Successful Product team\u2014\u2014the ten most important characteristics"},"content":{"rendered":"

Exactly a year ago\u00a0I was invited to give a keynote at the Craft Conference in Budapest and\u00a0I discussed the 10 biggest reasons\u00a0why product teams fail. \u00a0You can watch that talk\u00a0here<\/a>, or read the narrative article\u00a0here<\/a>.<\/p>\n

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 \u201cagile\u201d 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.<\/p>\n

Last week I delivered that talk, and this article is a narrative version.\u00a0 If you prefer to watch the video (1 hour long), you can find the presentation\u00a0here<\/a>.<\/p>\n

After the first talk quite a large number of people contacted me and asked for more information about the alternative. \u00a0Other than recommend to people that they read my book or attend a 2 day workshop, I didn\u2019t feel like I was able to give a very satisfying answer. \u00a0So 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>\n

CONTINUOUS DISCOVERY AND DELIVERY<\/h3>\n

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\u00a0Continuous Discovery and Delivery<\/a>\u00a0model (also known as Dual Track Agile, or Discovery Sprints and Delivery Sprints).<\/p>\n

KEYS TO SUCCESS<\/h3>\n

1. Empowered Product Teams<\/h3>\n

The most important characteristic of all is the absolutely fundamental concept of a strong product team. \u00a0But what does that really mean?<\/p>\n

First, it\u2019s essential that the team is durable; the members are not meant to be moved around like chess pieces. \u00a0If they want to actually innovate, they need the time to get to know each other, their technology, their customers, and the business context.<\/p>\n

Second, the chemistry of the members of the team is key. \u00a0This 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.<\/p>\n

Third, this means that teams have the necessary skill-set diversity, which is typically product management, user experience design, and engineering. \u00a0In many cases we would add to this list data analysis and user research.<\/p>\n

Finally, despite being a sensitive topic for many companies, it is hard to argue with the advantages of a co-located team. \u00a0Co-location means that the product manager, product designer, and the engineers (or at least the tech lead) all sit right next to each other. \u00a0We can\u2019t always achieve co-location for all of our teams, but we try. \u00a0And just to be clear, having teams in multiple locations is not the issue, it\u2019s when a single team is split up that causes the negative impact to both velocity and especially innovation.<\/p>\n

2. Product Vision and Strategy<\/h3>\n

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. \u00a0This starts with a clear and compelling product vision, and a path to achieving that vision, which is referred to as the product strategy.<\/p>\n

The product vision describes the world we are trying to create, typically somewhere between 2 and 5 years out (longer for hardware efforts).<\/p>\n

The product vision must be inspiring. \u00a0When done well, it is one of our most effective recruiting tools, and motivates people to come to work every day. \u00a0Strong technology people are drawn to an inspiring vision. \u00a0They want to work on something meaningful.<\/p>\n

The product strategy is our sequence of products we plan to deliver on the path to realizing the vision. \u00a0It would be a very poor strategy to try to please everyone with a single product release. \u00a0Instead, we have a prioritized list of markets, geographies, or personas and we focus on achieving product\/market fit for each of these markets.<\/p>\n

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.<\/p>\n

Most importantly, the product vision should be inspiring, and the product strategy should be very intentional.<\/p>\n

3. Focus on Business Outcomes<\/h3>\n

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. \u00a0The OKR (Objectives and Key Results) system is intended to facilitate precisely this.<\/p>\n

The OKR\u2019s reflect the list of specific business problems that the team is being asked to solve. \u00a0These are not features. \u00a0Features are only potential solutions to problems. Launching a feature is not success for a team; solving the actual business problem is.<\/p>\n

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. \u00a0Shipping features on a roadmap is output, solving business problems are results.<\/p>\n

4. Competent Product Manager<\/h3>\n

Sadly many engineers have never had the opportunity to work with a capable product manager. \u00a0The ones that have are the ones insisting that they always have such a person on their team. \u00a0Even worse, many engineers don\u2019t even know what the product manager is supposed to be contributing to the team.<\/p>\n

Think of it this way. \u00a0In order for a product team to solve hard business problems, it\u2019s not enough that the solution just work technically, and it\u2019s also not enough that the customer loves it, but also, and often most difficult, the solution must actually work for your business.<\/p>\n

Think about what this means. \u00a0Imagine you are working for Uber or AirBnB and you have to navigate complex laws and unions and trade groups. \u00a0 Or eBay which had to navigate significant constraints to be classified as a marketplace rather than an e-commerce site. \u00a0Or Tesla which had to navigate liability issues with Autopilot. \u00a0Every company has a list of these types of constraints.<\/p>\n

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.<\/p>\n

Unfortunately, in many cases the only person that has done the work to understand all of them is the CEO, and if that\u2019s the case, you can imagine why he or she might not feel comfortable truly empowering the team to make decisions.<\/p>\n

There are really three options to how teams work. \u00a0One is that the CEO or some other exec decides everything. \u00a0The second is that the weak product manager schedules a big meeting and invites all the executives into a room and they argue it out \u2013 this is called design by committee \u2013 which consistently produces weak results. \u00a0The 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.<\/p>\n

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. \u00a0But also one that\u2019s absolutely key to a strong product team especially if the team wants to have any meaningful degree of autonomy.<\/p>\n

5. Collaboration-driven Solutions<\/h3>\n

I am not saying \u201ccollaboration\u201d here as a buzzword. \u00a0What I mean by this is that rather than a product manager handing down \u201crequirements,\u201d and a designer making things pretty, and engineers just there to code what they are told to, instead, the three skills \u2013 product, design and engineering \u2013 truly collaborate to solve the problems. This is because with good solutions, the technology drives the functionality as much as the functionality driving technology. \u00a0 The technology enables design options as much as design drives technology selection. \u00a0And design direction drives functionality as much as the other way around.<\/p>\n

The point is that the technology, the user experience design, and the functionality, are all completely intertwined. \u00a0We come up with good solutions with a constant back and forth, give and take, between the three.<\/p>\n

The need for these collaboration-driven solutions is the single biggest reason why co-located teams consistently out-perform distributed teams.<\/p>\n

6. Product Discovery: Learn Fast<\/h3>\n

Much of great product boils down to the ability for the team to try out lots of ideas quickly. \u00a0We want to quickly separate the good ideas from the bad. \u00a0Product discovery is a broad set of techniques intended to help us learn quickly which ideas will fly and which are not so great. \u00a0Some ideas are big and some are small. \u00a0Some are risky and some are expensive. \u00a0Sometimes we need proof, and sometimes we just need evidence.<\/p>\n

Lots of people describe this is different ways. \u00a0Some like to describe this as \u201cfake it before you make it\u201d and some like to emphasize the \u201cbuild things that don\u2019t scale\u201d point. \u00a0The key is we need to learn fast and minimize waste.<\/p>\n

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.<\/p>\n

7. Focus on Key Risks<\/h3>\n

There\u2019s a couple important points to emphasize about product discovery.<\/p>\n

The first is that we need to focus on the four key risks: \u00a0value risk \u2013 would anyone buy this or choose to use it?; usability risk \u2013 would they be able to figure out how to use it?; feasibility risk \u2013 can our engineers build this with the technology available, the time available, and the skill-sets available on the team?; and stakeholder risk \u2013 are the different parts of the company ok with this proposed solution?<\/p>\n

In product discovery we are looking for good answers to these four questions. \u00a0If 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.<\/p>\n

8. The Role of an MVP<\/h3>\n

The concept of an MVP is one of the most important concepts in product yet it\u2019s also one of the most abused and misunderstood concepts.<\/p>\n

It\u2019s always dangerous to generalize, but I\u2019m going to go out on a limb here and argue that an MVP should never be a product. \u00a0In every single case I have ever encountered, when the team spent the time and the money to build an actual QA\u2019d 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.<\/p>\n

So an MVP is an experiment; a test. \u00a0It\u2019s usually one of the forms of prototype. \u00a0Often that\u2019s a user prototype, sometimes it\u2019s a live-data prototype, sometimes a feasibility prototype. \u00a0And sometimes they\u2019re hybrids. \u00a0In every case, it\u2019s a fraction of actually building out a real product.<\/p>\n

9. Product Delivery: Release with Confidence<\/h3>\n

My point here is not to tell developers how to build and release software. \u00a0Actually quite the contrary. \u00a0One of the issues that comes from the prior issue where teams use the engineering team to create these MVP\u2019s, \u00a0is that the engineering team is often pressured to release software that they know is not really something that should be released. \u00a0It\u2019s not something they feel comfortable standing behind. \u00a0There might be major reliability issues, or scale issues, or performance problems. \u00a0But the product manager keeps saying \u201cit\u2019s just an MVP, so relax!\u201d<\/p>\n

I\u2019m suggesting here that when it comes to software that your customers are actually depending on to run their business, you should not compromise. \u00a0We have plenty of good product discovery techniques for testing MVP\u2019s in ways that protect our customers, our revenue, our reputation and our own employees.<\/p>\n

So use your best practices, and only release true products to production when you have the necessary confidence in that release.<\/p>\n

10. Obsess Over Customers<\/h3>\n

The final point I\u2019d like to make is a bit different. \u00a0Nearly every company I meet tells me how much they love their customers. \u00a0It\u2019s usually somewhere in their company values or mission statement, but I have to tell you that it\u2019s easy to say the words, but much harder to actually follow through.<\/p>\n

I can tell pretty quickly when I talk to the team. \u00a0If a customer production issue comes up, how do they respond? \u00a0What level of urgency is there? \u00a0Does the team reach out directly to customers to understand if they need to? \u00a0Do team members know customers by name? \u00a0What type of relationship do they have with customers? \u00a0Do they consider the customers a big pain, or do they consider them more like colleagues?<\/p>\n

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.<\/p>\n

I hope this gives you a better sense of what makes great product teams great.<\/p>\n

The article is from:http:\/\/svpg.com\/product-success\/.<\/p>\n","protected":false},"excerpt":{"rendered":"

Exactly a year ago\u00a0I was invited to give a keynote at t…<\/p>\n","protected":false},"author":3,"featured_media":1968,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"jetpack_featured_media_url":"https:\/\/www.yibo.net\/wp-content\/uploads\/2016\/12\/1378175891576.jpg","_links":{"self":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts\/1975"}],"collection":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1975"}],"version-history":[{"count":4,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts\/1975\/revisions"}],"predecessor-version":[{"id":1981,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts\/1975\/revisions\/1981"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/media\/1968"}],"wp:attachment":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}