Hacking Within An Enterprise: From Startups To Intrapreneurship

Jenn Dearth at UXDX Europe. Video: https://youtu.be/l5SlKJxxkMQ

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From startups to Workday

[00:00:00] Hi, I'm Jenn Dearth, and I'm excited to be sharing with you what I've learned when it comes to adapting startup techniques to building products in an enterprise product company. I'm assuming that this audience is made up primarily of product folks who work in medium to large size enterprises, and you're looking to learn a little bit more about how to apply startup techniques and mentality in an enterprise. So let's dive in.

[00:00:25] Like most product managers, my background was anything but straightforward. I studied neuroscience and behavioral biology, and later got my master's in biomedical technology, focusing on management and development. These are the places that I've worked. It's probably obvious that none of them were enterprise product companies. The one in the middle was a startup that I started about a year out of college that focused on building educational video games to teach children mathematics, specifically in public schools in Washington DC. At Accenture and Pivotal Labs, I was a consultant where we practiced product management, but again, that's very different than working inside of a large product company. At GetWellNetwork, there were fewer than 200 employees, and at Stedi I was employee number three.

[00:01:15] I've read almost every book on product management, specifically in startups, and they all bubble up to these high level principles: eliminating uncertainty through validated learning, making sure that there's a tight feedback loop through Build-Measure-Learn cycles, always adding customer and user value, and then building products with a cross-functional or a balanced team. But then I joined Workday in March of 2019, which actually feels almost like a decade ago, given this pandemic and having two young kids at home.

[00:01:47] For those of you who don't know much about Workday, it was started in 2005 by ex-PeopleSoft executives. We're a financial and human capital management SaaS company with over 42 million users across 3,000 customers, one of which is Walmart, who has about 1.7 million employees. We just closed our first $1 billion quarter in July of this year.

[00:02:14] While the frameworks and cultural tactics, like Kent Beck's Extreme Programming and Ash Maurya's Lean Canvas, were still helpful, they needed to be adapted in order to be useful in an enterprise setting. Here are three key learnings that I'll be reviewing with you, including the framework adaptations for enterprises. The first is to find champions and evangelists on other teams who are willing to commit to your product and vision, and we'll be adapting the desirability, feasibility and viability Venn diagram. The second learning is about managing multiple dependencies, and we'll be adapting the two-by-two prioritization matrix. And finally, fight the urge to disrupt everything, and find ways to build "intergenerationally." I'll speak a little bit more about what that word means, but specifically, understand what to keep and what to modernize.

The assumptions behind this talk

[00:03:09] In line with the product management practice of listing all your assumptions out up front: this talk assumes that you have already validated that a customer problem exists, whether you've done your testing of your riskiest assumptions, you've done validated learning cycles, et cetera. Instead, this talk focuses more on solution execution.

[00:03:30] The second assumption is that you work in an organization that is obsessed with customers, which means you're talking to customers on a weekly or biweekly basis. I can't emphasize the importance of continuous discovery enough; Marty Cagan calls this dual-track agile. Make sure you're doing that alongside your continuous development. The third assumption is that you work in an organization where leadership empowers its employees, as opposed to dictating what should be on each product roadmap.

[00:04:04] The last assumption is that the organizational culture is trusting and promotes collaboration. If there's a lack of trust or transparency, or misalignment across the org, or there isn't this natural habit towards cooperation, then some of these hacks might not land for you. Ultimately, each of these assumptions can be a talk in and of itself, so I just wanted to state these up front before diving in, so that this talk is scoped appropriately.

[00:04:34] If these assumptions are not true for you, your mileage may vary. However, even if some of the assumptions aren't true for you, I hope there may still be small things that you can glean from this talk, even if it's as small as changing your perception about how you might be able to effect change. 2020 has been a year to challenge our perceptions, to try and focus on things that we can change, and learn lessons, even when the world feels just a little bananas.

Hack one: find champions on other teams

[00:05:01] All right, let's get started. Hack number one: find champions and evangelists on other teams who are willing to commit to your product and vision. If you've ever worked in a startup environment, you've probably seen this framework. Any product idea needs to be desirable, feasible, and viable. The desirable solution is the one that your customer or your user really needs; some frameworks, like jobs-to-be-done or design thinking, help suss that out. A feasible solution builds on the strengths of your current operational and technical capabilities. A viable solution has a sustainable business model; one of the tools there is Ash Maurya's Lean Canvas.

[00:05:45] If you miss any one of these, implementing the idea becomes riskier and costlier. This is how startups operate. There's a real emphasis on speed, iterating quickly, running experiments. Jeff Bezos was famously quoted as saying, "If you double the number of experiments you do per year, you're going to double your inventiveness." While this is all true, one important factor that is missing on the screen, and that is crucial for enterprises, is "other teams."

[00:06:07] At Workday, there are over 40 product areas. Workday releases biannually. Once every six months feels pretty painful, especially coming from the cadence of Pivotal Labs' one-week iterations. But the six-month release cycle was actually requested by customers. They wanted Workday to start shipping less frequently, because it's too difficult to keep up with all the new releases across all the various product areas. And again, there are 40 of them.

[00:06:40] Another thing that was new to me was this concept of tools versus apps teams, or frameworks versus solutions teams. Some companies call them pillars or verticals. Regardless of the naming, the cross-team, cross-org coordination is key to your product success. As a tools team, you're often one step removed from being customer facing. Instead, you're building something that will service the app teams, and once the app team uptakes your product, that's when customers and end users will actually see it. As an apps team, you are similarly shopping around for tools teams to partner with in order to accelerate your product development.

[00:07:19] Sussing out which app or tool team you want to partner with is a lot like dating. There's an opportunity cost for both of you. If you commit to each other, you aren't able to say yes to other opportunities, so it requires you to spend time up front to see if it's truly a smart match. You not only have to consider what the end user wants; you also have to consider what the app team or tools team might want, and getting commitment can sometimes be hard.

[00:07:45] I would adapt this diagram to also include, in terms of desirability: do you have strategic alignment with the other team? Are you solving a high priority problem for them? In terms of feasibility, the technical details matter. How interoperable is their technology compared to yours? Does it change the end user experience at all once you do the integration? And in terms of viability, can they actually fit you onto their roadmap, and can you fit them onto yours?

Workday Slides and Discovery Boards

[00:08:18] Let's take a look at what this looks like in practice, and where this lesson hit home for me. One of the products I manage is a presentation tool, specifically for your Workday data. One of the key value propositions of the product is the ability to refresh data with one click, instead of running a report in Workday, exporting it to Excel to munge the data, exporting it again to PowerPoint to present the data, and then doing it all over again next month. If you're doing something like a monthly headcount report, you can just click one button, "Refresh linked data," and then spend the majority of your time providing narrative and context around that data.

[00:08:57] Earlier last year, we started having conversations with the analytics team, who were building a brand new form of visualized reporting called Discovery Boards. Doing an integration between Discovery Boards and Workday Slides checked all the boxes in terms of strategic alignment. The analytics team had heard over and over again from their customers that data without context and narrative is useless. They really need to be able to say what's happening with the data. If they brought their Discovery Boards in and were able to comment on them and surface that context, it would be really, really valuable. Not only that, analytics is a key investment area for Workday in general, and for Workday Slides' long-term vision of being the last mile of every data story.

[00:09:44] In terms of technical details, we had already been working very closely with the analytics team through a sister product, Worksheets, which I'll be talking about later on in the presentation. So that wasn't a problem, but the timing got us. They were also a brand new product trying to get out the door, with a long list of backlog items. So while they were really excited about the prospect of the integration, they just couldn't make the time.

[00:10:10] Here's the hack. Find champions and evangelists; get commitment from other teams early. When I say commitment, I don't mean, "Oh yeah, great, you start working on it, and we'll join you once our backlog frees up." I mean, if you stop working on that integration for a week, the VP of that other org comes knocking on your door.

[00:10:31] Since the analytics team was busy, we started back at square one by asking the question: what other valuable processes are rich with Workday data that has to be presented? With 23 customer research interviews, a little elbow grease and a little executive sponsorship, we were able to ship just a couple of small features to complete an MVP for creating a talent dossier, which was enough to get the talent app team really excited about it and to champion it. There was a product manager on their team who wrote a nine-page how-to guide and shared it with their talent customers. There was an HR business partner who loved the use case, showcased it during an internal innovation competition, and ended up winning with the solution.

[00:11:21] Similar to dating, commitment is key. Being able to think of what the signals are will be important for you and your team, to gauge early on if the other product team is serious about working together. Make sure that they have skin in the game as well, like promoting a solution directly to their customer base, as the talent team did. If possible, define early on what an interim commitment milestone might look like, and start listening for those.

Hack two: don't only chase the fewest dependencies

[00:11:48] All right, hack number two. Don't just go after features that have the fewest number of dependencies. You've probably seen this two-by-two prioritization matrix before. The X axis is for organizational effort. The Y axis is for customer and user value. No-brainer, must-do items or features sit in the top right quadrant, because they're not that difficult, but they bring incredible value to your customers and users. The top left quadrant features are pretty difficult to implement, but also bring incredible value, so you need to think carefully about how you want to prioritize. The bottom right is easier to implement, but might not move the needle when it comes to value to your customer and user. And on the bottom left, just don't do it.

[00:12:33] Again, let's use a real product example to bring this framework to life. The other product I manage is an email template designer. At a startup, we would start by writing out all the necessary features: how do we allow users to create a layout, enter content, what kind of content do we want, add a subject line. Call it a day. We ship it in two weeks, and we gather some feedback.

[00:12:53] But what if you're Workday and you have a customer like Walmart, who has 1.7 million employees? What if you sent around 250 million emails a month, roughly 3 billion a year? Some of what we call Workday Awesome Sauce are features that really help with this at-scale problem, like conditional rules, where you can automatically serve up different content based on the audience, like if you're sending something to a warehouse worker versus a marketer versus an engineer. There's a lot more that we can do to help surface the right message at the right time for the right recipients, in order to prompt them to take action or raise awareness. However, this of course adds complexity to the product, as well as the product development process.

[00:13:41] Typically, in this framework, anything that falls in the top right quadrant you should just be continuously picking up from the backlog and prioritizing for your team. These maybe quadrants are where the hard work starts. When we think about those Workday Awesome Sauce features, those are definitely things that we know customers want, so I'd put it here, off the charts in terms of valuable. But it depends on three teams, and coordination with another two teams that are also prioritizing similar features for their products.

[00:14:07] On the other hand, we also know that customers just want to be able to send out really, really ridiculously good-looking emails, even with the product as is. No fancy Workday Awesome Sauce. There are still wins to be had in increasing the number of product areas that can use our new email template designer.

[00:14:32] Here's the hack. All the axioms, that focus is key and finished work is incredibly valuable, are all still true. However, it's up to you as a product manager to make sure that there's a diverse mix of long-term, short-term, and maybe even a couple of midterm features on your product roadmap at any given time. Short-term wins will keep the team engaged and motivated; the feeling of momentum is crucial. The medium-term wins might be harder, but they're still doable within the six-month time frame.

[00:15:05] The long-term features have a lot of dependencies, but you can't just continue to kick the can down the road and only pick off low-hanging fruit. What conversations do you need to get started now? What early signals of commitment can you start tracking now? What ways can you start building trust with other teams right now? You can get those shorter wins under your belt while you continuously and steadily march towards the features that will bring your long-term product vision to fruition.

[00:15:31] Contrary to my startup experience, where you were tasked with focusing on only one thing, enterprises require you to have at least two or three at any given time. I could give a whole talk on how to manage and prioritize streams, and how they're different from epics, but we'll save that for another time. In summary, don't just go after features that have the fewest number of dependencies. Include on your roadmap features with and without dependencies, and work on them in parallel.

Hack three: build intergenerationally

[00:16:03] All right, hack number three. Find ways to build "intergenerationally." I lived in Washington DC for nine years, and I'm sure there are even more examples of this in Europe, but one of my favorite neighborhoods had these gorgeous traditional row houses, and they had immaculate modern interiors. There was something very elegant, compelling, and versatile about understanding what was structurally foundational and what could be modernized. This problem is unique to enterprises, because as a startup, you're the first generation.

[00:16:37] I remember when I first started at Workday, I was confounded by how long some processes took, and by the complexity of how difficult integrations worked. I kept saying to myself, there has to be a faster way. What if we just rebuilt it? So how do you identify what you should modernize and what you should leave in place? Use the principle of what won't change about your customers to guide you. For Amazon, it was cheaper goods and faster delivery. Those are things that are never going to change about consumers.

[00:17:11] Workday customers, all 3,000 of them, have come to love and trust our contextual security model. Contextual security makes it so that users can't see data that they aren't supposed to see. When folks run reports or tasks, customers rest assured knowing that nothing's going to show up unless the user's job position, supervisory organization, or title, et cetera, allow for it. However, this model can be really restrictive and makes it difficult for folks to collaborate.

[00:17:40] What we found through customer interviews is that users were just downloading the reports out of Workday, converting them into spreadsheets, and emailing them around anyway. So we evolved the security model to better mirror what was already happening in our customers' lives, but we were able to add guardrails, like allowing for more traceability. You're able to audit who it was shared with, where it was shared, when it was shared. Contextual security is still enforced when bringing in data or refreshing the data, but from there, the collaboration security model allows you to get your work done faster and more safely than bringing it outside of Workday.

[00:18:21] Through talking with customers directly, we learned that no one would have been comfortable without contextual security. Those are the strong foundational bones of Workday. But for specific use cases, where data is constantly changing and collaboration is critical, the collaboration security model solves a huge pain point.

The productivity suite as a beachhead

[00:18:42] One more example of how small waves can have a lasting impact on the company is the productivity suite. This is the organization where all the products that I've mentioned live. It started about five years ago. It is focused on building products on top of all the valuable Workday transactional data, security models, and business process frameworks, but with a facelift. All the products in the suite have a similar and familiar interface, which makes learning the tools quick and easy.

[00:19:09] Within the productivity suite, all five of these products actually ship software every single week. This organization was able to bring on its own pipeline engineering team, which has been able to practice continuous integration, even though Workday ships biannually. But it all started with one product, Worksheets. You just need a beachhead to start.

[00:19:34] This third hack is to fight the startup urge to disrupt everything and start from scratch. That can be hard to do with 42 million people living inside the house. At the same time, enterprises are notorious for being bogged down with legacy systems and not investing in the future, because there aren't immediate benefits. So this isn't to say never rebuild. Just be mindful of what you want to focus on, and use the long-term view of what won't change about your customers in order to drive that decision.

Summary and a closing thought on perspective

[00:20:06] In summary, here are the three hacks again. Working with other teams is inevitable when it comes to working in an enterprise, and it's a lot like dating. Take the time to build that trust, and use customer stories to bring forward the value of the integration and the features you're trying to propose. Number two, enterprises force you to have two to three concurrent streams at all times. And number three, discern what to keep and what to modernize, and focus on what won't change for your customers to guide you.

[00:20:37] I'll leave you with one last thought, and it's about perspective. When it comes to being able to hone your craft, I've heard from folks at startups who say, "Things are changing so fast, it's really hard to make time for it." Similarly, from folks who work at enterprises, I've heard, "Enterprises are so slow," or, "I'm only working on such a small widget in the overall machine." I'd say, get it out of your head that you can only learn in the perfect conditions. Have a growth mindset, and routinely reflect on what you've learned and what's working and what isn't, because all of those learnings ladder up to customer centricity. How can we improve the lives of our users?

[00:21:20] When you think about going to the office tomorrow morning, what is one thing you can do differently? It might be one of those three hacks that I mentioned, or it might be an idea about changing one of the fundamental assumptions that I mentioned at the beginning, like validating the customer problem by actually talking to customers, or lobbying your leadership for more empowerment. But the point is to just start.

[00:21:43] Taking the row house analogy even further, it might not feel like a lot to remodel a guest bathroom in a whole house, but you have to start somewhere. Just by finishing the bathroom, you actually are creating change. Having completed the bathroom, you are showing that things can change, and that you can radiate that change outwards more and more. And it won't be long before it looks like the Fab Five came to your house.

[00:22:10] Again, with the right perspective, let's focus on the things that matter and the things that we can control. Michael Sippey, the Head of Product at Medium, gave a talk at the Mind the Product conference last year, and he said that product people are like concertgoers, full of optimism. Crowd surfing is an act of trust, believing that others are going to catch you. So let's go out in the world with renewed optimism and trust, and build some awesome products for our users. Thank you so much.