Enterprise Product Management explained by Dropbox's Product Manager
•Download as PPT, PDF•
5 likes•1,452 views
This document summarizes an enterprise product management talk given by Ketan Nayak from Dropbox. The talk discusses some of the key differences between consumer and enterprise products, including that enterprise customers require more attention but provide more revenue per customer. It also goes through the product development cycle of ideas, roadmap, specs, delivery, and feedback. For each stage, it provides tips learned from experience such as getting customer feedback at every opportunity through various meetings and events. The overall message is that successful enterprise product management requires playing the long game of incremental improvements and close partnership with customers.
Recommended
Recommended
More Related Content
What's hot
What's hot (16)
Similar to Enterprise Product Management explained by Dropbox's Product Manager
Similar to Enterprise Product Management explained by Dropbox's Product Manager (20)
More from Product School
More from Product School (20)
Recently uploaded
Recently uploaded (20)
Enterprise Product Management explained by Dropbox's Product Manager
- 1. Enterprise Product Management explained by Dropbox's Product Manager
- 3. ABOUT ME ▸ Ketan Nayak ▸ PM at Dropbox ▸ PM at APT (acquired by MasterCard) ▸ Quant trading + manufacturing ▸ MIT, IIT Madras ▸ Talk to me about national parks
- 5. TODAY’S TALK IS JUST ME SHARING SOME STORIES AND GIVE YOU SOME TIPS ON SHIPPING ENTERPRISE PRODUCTS
- 7. ENTERPRISE IS AWESOME! BUT IT IS ALSO DIFFERENT
- 8. LOTS OF CUSTOMERS CONSUMER ENTERPRISE LESS ATTENTION PER CUSTOMER LESS REVENUE PER CUSTOMER SELF-SERVE NO REAL AGREEMENTS FEWER CUSTOMERS MORE ATTENTION PER CUSTOMER MORE REVENUE PER CUSTOMER SALES TEAM PILOTS, CONTRACTS AND SLAS
- 13. IDENTIFIES OPPORTUNITIES SMALL TWEAKS TO SELL TO PHARMA!
- 15. IDEAS Takeaway
- 18. 11%
- 19. PORTER’S FORCES EFFECT LARGE DEDICATED TEAM INDEPENDENT OFFICE SEPARATE DATA CENTER NEW PRODUCT DEV
- 21. ROADMAP Takeaway
- 28. SPECS Takeaway
- 32. CHANGE IS HARD, EVEN MORE SO IN ENTERPRISES
- 37. LISTEN AND WATCH YOUR CUSTOMERS AT EVERY OPPORTUNITY PRODUCT TRAINING SESSIONS SALES CALLS CLIENT VISITS USER CONFERENCES ROLLOUT MEETINGS
- 39. Play the tug of war with sales Watch for the whales Cupcakes for user AND buyer Feedback is more than looking at numbers Shipping: Does it really help?
- 40. TEXT
Editor's Notes
- Hi everyone, thanks for coming tonight to the info session. This is a great time to learn about product management and how to transition from your current career. Tonight, Vivek will be joining us. He is a Product Manager at Yelp. He is a wealth of knowledge when it comes to product, and has a great perspective on what makes an effective product manager. Tonight’s your chance to pick his brain! My name’s Laura and I handle admissions in SV and SF. We have graduated over 600 students in our NY, SF, and SV. View campuses.
- Thanks everyone for coming today and thanks Product School for having me! I’m Ketan and I currently work at Dropbox Story/Joke Today, I’m really excited to talk about product management for enterprise products When people talk about product management, they’re pretty much always talking about managing consumer products. You hear people talking about Uber, AirBnB, Facebook and so on… PMing for the enterprise gets far lesser love I want to shed some light on what it’s like being a PM in a B2B space
- A little bit more about myself: I’ve been a PM for more than 4 years now. I work at Dropbox as a product manager on analytics and growth. I’ve been there for a few months now and before that spent about 3+ years working in an enterprise product company called APT that then got acquired by MasterCard APT built retail analytics software for large chains stores such as Starbucks, Wendy’s etc. Before getting into PM I did a whole bunch of things from quant trading to manufacturing. I actually got into Product Management completely by accident and found that I loved it. If you’re interested in knowing how I made that transition, come talk to me afterwards Schooling wise, I went to IIT Madras for undergrad and then did a Masters at MIT I love national parks and the great outdoors! My current favorite national park is Zion, though the picture of me smiling happily is not from Zion but from Bryce Canyon which is nearby
- What does a product manager exactly do? Well, that’s hard to answer What does an enterprise PM do? That’s even harder to explicitly answer
- Instead Really, what I want to do is to share some of my stories and experience managing enterprise products from both PM roles that I’ve held In that process, I hope to give you a glimpse into what it’s like being in the shoes of a B2B PM I also want this to be practical for everyone here and will give you all some practical tips and takeaways that you can apply in your next PM role
- Why is enterprise worth looking at, though? Why should we bother about it? Presumably you’re all here because you’re interested in PMing enterprise products -> So I am selling to a biased crowd here But let’s look at a simple indicator: VC funding for enterprise software VC funding for enterprise has very much on the upswing in the past few years And as PMs or aspiring PMs, we should care for two reasons: More interesting enterprise problems are funded to be solved MEANS more opportunities for product solutions More demand for people with enterprise PM skills
- So great, lot’s of funding, lots of opportunities: Enterprise is awesome! Everyone agrees with me, right? Why talk about it then? Because it’s different. You read conventional articles on Medium, blogposts, books on PM and pretty most of it talks about consumer PM
- The enterprise product world is different from the consumer product world in lot’s of ways! Many differences fundamentally stem -> lots of customers in consumer (millions) vs. fewer customers for enterprise (100s or 1000s) Result : As a company you pay little to no attention to individual customers on the consumer side and pay more attention per customer on the enterprise side In the consumer world, you get less revenue from your customer (maybe a few dollars), but in enterprise, it is not unheard of for the the company sign massive deals with 6,7,8 digit contracts Consumers products are self serve or use consumer products directly, but enterprise needs a sales team, a sales engineering team to navigate the sales process Enterprise product adoption involves pilots, contracts and SLAs -> Consumer not so much and no real contracts What are examples? - I’m sure you can name many already, but at Dropbox, Dropbox basic is a consumer product whereas Dropbox for Business, when we talk about large enterprise licenses falls into the enterprise product space There are a lot more differences between enterprise and consumer
- I can give a laundry list of all the things that are different between PMing enterprise products and PMing customer products, And that’s not going to be a lot of fun Instead I want to talk about 5 key things that you’ll do as a PM and talk about how being in the enterprise is different Starting from, ideas, building a roadmap, creating specs for the things on your roadmap, shipping products/features and getting feedback Obviously, as a PM you’ll do a lot more than the 5 things mentioned here But it’s a good way for us to capture the core parts.
- Let’s talk about ideas. Ideas for your next product, ideas for the next feature. Where do you get ideas from?
- From lot’s of different places, sources and channels. You get feedback from your customers, through surveys, user research and focus groups You look at the market and you look at the competition (what’s the competition doing? Where are they headed?) Some great ideas are generated internally on your own teams As smart people keep thinking about the problems they are trying to solve, they usually come up with some pretty good ideas
- For enterprise products, a key channel of ideas is your sales team The sales team is actively staying in touch with your existing clients, potential clients or prospects and listening to them The team is also on the ground, having meetings, hosting dinners and attending trade shows And in this process they collect a host of valuable information about the client, the problems they’re facing and ideas for the product
- Your sales and sales engineering team can be incredibly helpful in finding and identifying opportunities that might often be hidden from you as a PM 1 time - > The sales team came to PM team (a group of about 3-4 PMs) to talk about problems faced in the Pharma industry and expanding into the Pharma vertical (remember that APT was focused mostly on retail). Based on what the sales team said , we figured that with small tweaks to the product, we could essentially sell retail analytics product to address problems clients in the Pharma industry were facing All that we had to do was to change some of the wording within the product and load the data in a slightly modified way and we were set! Can you believe that? It was amazing! -> In the PM world you look for 80-20s all the time, this was even better! It was like an 80-5 case! The product and the company could enter a new industry, generate a completely new source of revenue, with very little work! Why did this happen? This happened because sales was consistently pursuing new prospects, even though they didn’t fit the traditional client profile. And the PM team and the sales team maintained an open line of communication
- At the same time you don’t want to give too much leeway to Sales or your sales engineering teams. If not, they come back to you with must implement ‘ideas’. This is one of my favorite Dilbert strips. It illustrates that subtle balancing act that we as PMs need to play in interacting with the sales teams as well as with our own engineering teams There is always high probability for something like this to happen when there is a sales opportunity that is hard to miss. When APT was looking to enter the Australian market for instance and sell to one of the top banks, the sales team ended up promising a non-existent feature with a delivery date to get the deal signed. As I asked engineers to work on this, I felt terrible, but there was simply no way around it To honor this contract, the engineering team had to scramble to deliver the feature on time and stuff like this doesn’t make engineers happy.
- Our first take away is that as a PM, you need to play that tug of war with sales when it comes to ideas and considering it for implementation Sometimes you get great ideas from your sales team, and sometimes you simply need to hold your ground Same thing at Dropbox: We have an enterprise sales team that provides a client requests to the product team on a regular basis. And it is up to the product team to consider and prioritize the requests
- Next up is one of my favorite words: Roadmap It’s this place that holds exciting things for your customers and is the place where your dreams and vision materialize
- Once you have all the different ideas, you need to prioritize them so that you can tell your engineering team the order in which they need to be worked on and to build a roadmap for your team There are lots of ways to prioritize and you whip up a tried and tested cost-benefit matrix to decide the order Voila! The prioritization matrix tell you what’s most important and you now have your roadmap Plus, the engineering team knows what to expect and is set up for success Right? Not really
- Enter Walmart. Walmart is a behemoth in the US retail industry. Especially when you consider US retail chainstores, it clearly the queen. Even today, Walmart accounts for about 11% of total US retail sales (Meaning 1 in every 9 dollars being spent on retail is being spent at Walmart). amazon.com, might be eating into their share slowly, but that’s a different story What does that mean? If you’re competing in retail, Walmart is the biggest fish out there. Within retail, Walmart is one of the hardest clients to acquire and having Walmart as a client makes it substantially easier to acquire other clients
- Now, Walmart was one of 100+ clients at APT Major clients like this on your enterprise product exert a porters force type effect on your product and your entire org They have a huge bargaining power as a key buyer of your product and services Within an enterprise company, it’s not atypical for a single client to drive 30, 40, 50% of your revenue Walmart didn’t even account for such a large percentage of revenue, but they still enjoyed a host of benefits that other clients didn’t: They had by far the largest dedicated client services team A separate office in Bentonville, Arkansas (head quarters of Walmart ) for Walmart and it’s affiliates Walmart had a separate data center to which we had to separately run code deployments. For every other client, the data was hosted on our own server We had another independent team building new products just for Walmart and affiliates What did it mean for our roadmap? It meant that if Walmart wanted a feature, we prioritized it and pretty much built it right away ahead of others
- My first feature as a PM was to help Walmart publish specific results from our product to their internal reporting system In concept, the feature was fairly simple. For each result, we had to allow users to add a flag: Is the result published or not? Flagged results would then show up in Walmart’s internal system via a script Not only did we prioritize this feature ahead of other features on the roadmap, but because of the urgency we came up with a super hacky implementation On the results table (which was a generic table in a data model), we added a client specific column called publish results for Walmart just for their use case We would have never done this for any other client in a million years What was the worst part after all this? Me and my engineering team spent weeks building this feature and users never used it. :( At Dropbox, when you have an enterprise client looking to sign a potential large contract and there there will usually be product requests
- An enterprise PM, be aware of the whale among your clients By wielding large influence on your company and your team, they can request features or enhancements and rock your roadmap ship at any time And it’s your job as a PM to make sure your team is appropriately shielded from the impact and to navigate your team through the work
- Now we’re getting to the meat of things. Once you have your roadmap ready, you dive into creating the requirements so that your engineers can build the set of features that your users have always wanted
- At Dropbox, one of our company values is simply a cupcake -> represents the delight that a user feels when they use the product As a PM, when you write product specs to build a product or a feature, you want to delight the user in the end You’re always striving to have your end users feel that experience
- To get the cupcake for your users, while writing product requirements you need to think deeply about your user their goals, their business objectives and the strategic fit of what you’re trying to solve You then think about user stories, how solutions fits into their life And finally you use that to drive the design for the project and get to the product spec
- The enterprise however, world is different -> the person that pays for the product is different from the person that uses your product You don’t just care about your end user, but you need to care about the person that swipes the credit card, writes that check and is the decision maker for the client adopting your product Couple of key ways in which this manifests: When enterprise clients look to adopt a product, they usually run a pilot of the product first. If that trial is deemed successful , they license it for the longer term. When making the decision for a longer term license following the pilot, the success of your product depends on the key decision maker (not the individual user but the buyer). Ideally you want the decision maker to be a champion for your product In early stage products that are in growth mode, you also tend to think more about the buyer because it is those folks that you’re meeting and trying to get to pilot your product.
- 5-10 years ago, enterprise product development was mostly buyer and decision maker driven You look at legacy enterprise software systems and it was just a bunch of functionality crammed in with very little thought given to the UX Why? Because that’s what buyers cared about and their needs were prioritized ahead of actual end users In the past few years, this has changed completely. Now, pleasing just buyer or user’s boss is no longer enough Slack for instance is a wildly successful enterprise product and they are mostly design driven. They prioritize good design ahead of most other things
- How does this manifest at dropbox? Dropbox is a collaboration product, and our end users care about features around collaboration, sharing, previews and a lot more. It is of utmost importance that we as a company provide the best experience for our end users At the same time we don’t ignore what the decision makers care about. What do the buyers/admins care about? They care about the Dropbox administrator experience, access controls, security features, ease of deployment and integration At larger enterprise companies - how does this all work? You’ll be the PM for one of these teams and will closely collaborate with other PMs that think about the complementary user groups and constantly think about how the the experience evaluates across both user groups
- When you write specs you need to think of users and cupcakes But when building enterprise products, you need to bring not one, but two cupcakes to the party One for the user and one for the buyer Both your user groups should love the product, experience the delight and only then will your product be truly successful
- Finally, it’s delivery time or time to ship! The most exciting time for a PM. The culmination of the weeks and months of hard work by you and your team! So you did all this work, got the user research, figured out the use cases, wrote requirements, worked with your engineers to build out the product.
- And….. you find out that clients don’t want your feature! And you wonder, How did this all happen?! What went wrong?
- The key insight is that it takes time for a client to adopt your enterprise product The users at your client have to take time to learn product and go through a steep learning curve Your product is not going to sit in a silo by itself, and instead is going to be integrated with other systems and products that your client users Your users having learnt your product and created these integration points will then create workflows for themselves that now includes your product.
- Clients and users have invested so much time to learn -> they are resistant to changes -> break or modify their workflows Ship something that makes product nicer -> users evaluating it in the overall scheme of their workflows -> hard to quickly adapt mantra of ship fast and break things -> not just breaking SLAs and contracts, but breaking the very workflow your users have built up Let me share an example of an experience that I had that led to a failure mode I was once looking to ship a feature to improve Excel exports from the product Now, users had always been asking us for richer data in their exports. But shipping a richer export was tricky because lots of users had built macros on top of the Excel export format All of these would break if we introduced a new Excel export with modified data So we had to do a lot more work to make sure that the shipping went smoothly
- The key takeaway -> you’re delivering a feature in the enterprise -> announce in advance and prep your users Give them time to adapt to the new feature. Just don’t automatically switch features on! And always remember by shipping something automatically you might inadvertently break something, so watch for that. Think about training your users, to help them make the best use of the feature. Often you’ll end up working very closely with the customer success team or its equivalent on the delivery.
- Finally let’s talk about feedback and come full circle.
- A/B tests are a key way to collect feedback from users in the consumer world. It’s really a standard process & you can’t do without it AirBnB - 3000+ experiments - any point in time users are exposed to 100s of expt In A/B testing, you expose a random subset of of your users to a feature or variant ->and compare performance to the control variant You then use statistical significance to determine if the feature being introduced helps or hurts Once you make the decision to ship, you then slowly roll out the feature and ramp up the release to alpha, beta, 5%, 10% of the user population and so on. At any point you see trouble, you can hold off from ramping more or roll back In enterprise products however, there are two major obstacles to A/B testing:
- The first is that there are substantially fewer number of clients and users in an enterprise product What that means is that you simply don’t have enough traffic on product surfaces to reach statistical significance Especially if the feature you’re launching is on a button somewhere on a page deep within the product, then your situation is even worst Running an AB test to significance, then takes too long and is simply not practical In consumer products on the other hand, you have millions of customers and AB tests are very effective The second issue is Bias - There are lots of ways in which bias can get introduced into your system A/B testing works on randomization of users. In an enterprise product you simply might not be able to randomize your experiment and instead have to provide a consistent experience to all users within a company.
- How can you get direct feedback from customers then? Obviously, you have other channels of feedback like the sales team or the sales engineering team Instead, one of the better ways to get product feedback is to listen and watch your customers at every possible opportunity Look to attend rollout meetings, where clients decide to sign on a long term license. In these meetings, you’ll truly come to know what their criticisms of the product are Attend training sessions, sit in on sales calls, visit clients and meet them in conferences
- Key takeaway is that it’s not all about the numbers It’s okay if you’re not using a ton of analytics to slice and dice data in every which way It’s okay if you’re not running a ton of A/B tests to optimize your product in every way possible You care more about what your actual users are telling you and showing you You care a lot more about the relationship between your product, your company and your client
- So, what did we cover today? The 5 take aways : In getting ideas for your product and considering them -> Play the tug of war with Sales As you prioritize things from your backlog and put them on your roadmap -> Watch for the whales Delight not just your users, but your buyers as well -> Bring 2 cupcakes to the party Think about how what you build for your user might not really help them Finally, feedback is more than looking at numbers, it is listening to your customers, watching them and as a company building relationships
- Thanks for listening to the talk I’m now happy to take any questions.
- Thank you!
- Hi everyone, thanks for coming tonight to the info session. This is a great time to learn about product management and how to transition from your current career. Tonight, Vivek will be joining us. He is a Product Manager at Yelp. He is a wealth of knowledge when it comes to product, and has a great perspective on what makes an effective product manager. Tonight’s your chance to pick his brain! My name’s Laura and I handle admissions in SV and SF. We have graduated over 600 students in our NY, SF, and SV. View campuses.