Hacking Within An Enterprise: From Startups To Intrapreneurship

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 and 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.

Like most product managers, my background was anything but straightforward. I studied neuroscience and behavioral biology, and later got my masters in biomedical technology focusing on management and development. These are the places that I've worked. 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.

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, and then 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. For those of you who don't know much about Workday, it was started in 2005 from ex-PeopleSoft executives. We’re a financial and human capital management SAS company with over 42 million users across 3000 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.

So, 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. So, 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, the fight—the urge to disrupt everything, and find ways to build “intergenerationally”. And I'll speak a little bit more about what that word means. But specifically, you know, understand what to keep and what to modernize.

In line with the product management practice of listing all your assumptions out upfront. This talk assumes that you have already validated that a customer problem exists through whether you've done your testing, your riskiest assumptions, you've done validated learning cycle, et cetera. Instead, this talk focuses more on solution execution. 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. Can't emphasize the importance of continuous discovery, Marty Cagan calls this Dual-Track Agile enough. So, making sure you're doing that alongside your continuous development. The third assumption is that you work in an organization that leadership empowers its employees, as opposed to dictating what should be on each product roadmap. And 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 upfront fledged before diving in, so that this talk is scoped appropriately. And so, 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 affect 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.

All right, so 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 using design thinking to 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. Some of the tools, there are Ash Maurya's Lean Canvas. But 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.” And while this is all true, one important factor that is missing on the screen that is crucial for enterprises are “other teams”. At Workday, there are over 40 product areas. Workday releases by annually. 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 and all the various product areas. And again, there are 40 of them. Another thing that was new to me was this concept of Tools versus Apps teams, or Frameworks versus Solutions team. 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.

So, sussing out which app or tool that 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 upfront 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. So, 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?

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 in Excel to munch the data, exporting it again to PowerPoint to present the data, and then to do it all over again next month. If you're doing something like a monthly headcount report, you can just click one button, “Refresh link data”. And then spend the majority of your time providing narrative and context around that data. 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. So, if they brought their Discovery Boards in and was able to comment on it and be able to bring that surface, that context, it would be really, really valuable. Not only that, an analytics is a key investment area for Workday in general, and for Workday slide’s long-term vision of being the last mile of every data story.

In terms of technical details, we had already been working with—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. There are also brand new products trying to get out the door with a long list of backlog items. So while they're really excited about the prospect of the integration, they just couldn't make the time.

So, here's the hack. Find champions and evangelists, engage commitment from other teams early. And when I say commitment, I don't mean, “Oh yeah, great. You start working on it, and we'll start—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. 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 up just a couple 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 that wrote a 9-page how-to guide, and shared it with their talent customers. There was an HR business partner who loved the use case, and also showcases it during an internal innovation competition and ended up winning for the solution.

Similar to dating, commitment is key. So, being able to think of what 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, like the talent team did. If possible, define early on what an interim commitment milestone might look like and start listening for those.

All right, hack number two. Don't just go after features that have the fewest number of dependencies. So, you've probably seen this two-by-two prioritization matrix before. The X axis is for organizational effort. That Y axis is for customer and user value. But 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 hand 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.

So again, let's use a real product example to bring this framework to life. The other product they manage is an email template designer. At a startup, we would start by writing out all the necessary features, like how do we allow users to create a layout, enter content, what kind of content do we want at a subject line. Call it a day. We ship it in two weeks, and we'd gather some feedback. 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 are sent a year. Some of what we call Workday Awesome Sauce. Our 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.

Typically, in this framework, anything that falls in the top right quadrant, you should just be continuously picking up from the backlog and prioritizing it for your team. And these Maybe quadrants, this is 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. 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 for increasing the number of product areas that can use our new email template designer.

So, here's the hack. All the axioms of focuses 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 even maybe a couple of midterm features on your product roadmap at any given time. Short Term, we'll 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. 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 can you—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 into fruition. 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 than 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.

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 interior. 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. I remember when I first started at Workday, I was confounded by how long some processes took. The complexity of how difficult integrations work. And 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? So, thinking through the principle of what won't change about our customers to guide you. For Amazon, it was cheaper goods and faster delivery. Those are things that are never going to change about consumers. For Workday customers, all 3000 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. So when folks run reports or tasks, customers rest assured knowing that nothing's going to show up unless the user's job position, supervisory, or title, et cetera, allow for it. However, this model can be really restrictive and makes it difficult for folks to collaborate. What we've 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 customer's lives. But we were able to add guardrails, like allowing for more traceability. You're able to audit who was it shared with, where was it shared, when was it 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. Through talking with customers directly, we learned that no one would have been comfortable without contextual security. Those are 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.

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 the facelift. All the products in the suite have a similar and familiar interface, which makes learning the tools quick and easy. 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 when Workday ships by annually. But it all started with one product, Worksheets. So, you just need a beachhead to start.

This third hack is the fight the startup urge to disrupt everything and start from scratch. It 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 will change about our customers in order to drive that decision.

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, 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 our customers to guide you.

I'll leave you with one last spot. 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 figure out or to make time for it.” Similarly, folks who work at enterprise, I've heard, “Ah, 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 continuously—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?

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 these fundamental assumptions that I mentioned at the beginning, like validating customer problem by actually talking to customers or lobbying for more empowerment to your leadership. But the point is to just start. 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. And 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.

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 concert goers, full of optimism. Crowdsourcing 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.