The Brent Tworetzky Hypothesis: Savvy COOs Can Use a Product Lens to Effectively Drive Company Operations

Brent Tworetzky is the COO of Parsley Health, where he leads product, finance, and operations. He co-founded and runs the NY Product Conference.

In this episode of the Product Science Podcast, we talk about how Brent has transformed his company by following product principles on an organizational level.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, and more. Love what you hear? Leave us a review, it means a lot.

Resources

• Follow Brent on Medium
• The Product Manager Superpower: User Science
• Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink
• Follow Brent on Twitter
• Connect with Brent on LinkedIn

Questions We Explore in This Episode

How did Brent get his start in tech as a front and backend database engineer? What problem did he run into working at large companies like Motorola and Microsoft? What drew him to the healthcare industry? Why was he drawn to product management? What was his first job in product? What was it like working at Mint and learning from an established product management process? What did Brent learn about integrating design into the process early? Why was consumer trust a core value for Mint, and what did they do to protect it?

Why did Brent have a hard time finding a business in healthtech that had a good user value proposition and felt scalable? How did that lead him to an edtech position at Chegg? Why was the product team in particular so exciting? Why is the head of product’s philosophy so important when it comes to sizing up what kind of learning experience you’ll get working at a company?

What was Brent’s experience like bringing user science to other companies that didn’t have an established framework? Why is the qualitative side of data less understood than the quantitative side? What’s the story behind Brent’s Medium post, “The Product Manager Superpower: User Science?” How do you use user researchers effectively when some of the things they do can overlap with UX and product?

When does Brent use diary studies and why? Why is it sometimes misleading to believe the first thing consumers say about why they’re not getting value from your product? How did understanding the complete customer journey with a diary study help Brent relaunch and double his metrics?

What was it like transitioning from leading teams to leading a team of teams? How do you collaborate across departments and keep aligned with the organization at large? How has Brent expanded his product principles to run a company that focuses on the right problems in the right way? How is being a COO similar to being a product leader? Why is it helpful to think about your company as a product and your employees as the users of that product? What KPIs does Brent use to measure success? What do you do when you see that you need to make changes? How do you simplify your systems on an organizational level? How do you navigate through periods of high growth where you need to go through this process several times?

Quotes From This Episode

In product, I found a job that uses technology where I can be a doer, a thinker, and get closer to something that really matters and touches me at the heart.

It feels 80% the same to be the COO of a company, where you’re ensuring that the company is operating well, and being the head of product and ensuring the product and design and engineering work well.

As COO, I think of a company as the product, the users of the product are the employees-- how do I make sure that the product is successful and the users are happy?

Transcription

Holly Hester-Reilly:

Hi, and welcome to the Product Science Podcast, where we're helping startup founders and product leaders build high growth products, teams, and companies through real conversations with people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host. Holly Hester-Reilly, Founder and CEO of H2R Product Science.

This week on the product science podcast. I'm excited to share a conversation with Brent Tworetzky. Brent is the COO of Parsley Health, where he leads product, finance and operations. He also co-founded and runs the New York Product Conference. Brent welcome.

Brent Tworetzky:

Thank you so much, Holly. It's great to be here with you and your listeners.

Holly Hester-Reilly:

Yeah. I'm super excited to share with people your journey to COO, obviously it goes pass through product. How did you get started in tech and product?

Brent Tworetzky:

Oh my goodness, it started such a long time ago in a galaxy far, far away. I started my career as an engineer, a kind of Jack of all trades, front end, backend, database engineer and loved the power of what technology could do. This is in the '90s. You could build things and have them appear before your eyes and personalize them and scale them. I loved computer science. I studied that. I majored in that.

However, I found it on my jobs that places like Motorola, which is a company people used to know about and Microsoft, places like that, that I didn't always know why I was doing what I was doing and I felt a little left out. I remember sitting in my office on a Friday in Microsoft and learning that day that we were one of four teams doing the same distributed database application and only one would survive and just thinking, "Oh my goodness, I'm putting all this love and craft into building something amazing and yet I don't know why. What's the why?"

From there, I moved from engineering into... I dabbled in different parts of business, I wanted to understand how business gets done and how we make decisions and strategy. I dealt with [inaudible] and consulting in DC and all those things, I loved the thinking part of product, but I was in... that ultimately was in product. I loved the thinking part, but in those other roles, I was thinking but I wasn't doing. Being a consultant for a VC, you think and you come up with big ideas, but you're not accountable for the doing.

Along the way I also learned in different industries, I love to work in places where the product really matters or the problem really matters to people. People in healthcare were much happier than people in magazines or movies or packaged goods. I combined that all I'm like, how do I find something where I can be a doer, the arms and legs, I can be the thinker, the brain, and I can get closer to something that really matters and touches me at the heart. How can I have a job that uses technology that is the head, the heart, the arms and the legs?

I eventually found that in product, in the mid-2000s, when this product thing was starting to emerge, and from there I fell in love and I said, "How do I do more of this? How do I put myself in a place to learn and grow and work on really important products?" Then there my product career started from that foundation.

Holly Hester-Reilly:

Yeah. I love the way you described that of the heart and the head and the arms, and the legs. What was your first product job?

Brent Tworetzky:

I unofficially had a product job as sort of an account manager at WebMD when I was making micro-sites for people and thinking about healthcare micro-sites, still writing specs and doing program management and thinking about users and looking at analytics. Back then, they didn't really have the... I was called the strategic account manager, because they didn't really have the term product manager back then.

The first time I was officially a product manager is when I joined a startup called Mint, personal finance startup and I just, I wanted to learn from someone who... from a place that did product really well and they had this awesome product leader named Aaron Forth, who is still a very successful product leader in our universe, he's gone on to lead product at many great companies. I was very lucky to learn from him and the team that he assembled. We had the eBay and the Amazon DNA of product at that company.

Holly Hester-Reilly:

Oh, awesome. How big was Mint at the time that you joined?

Brent Tworetzky:

We were 25 people.

Holly Hester-Reilly:

Definitely purely startup age.

Brent Tworetzky:

Very, very early. Then a year later, we were acquired by Intuit when we were at 50 people.

Holly Hester-Reilly:

Oh my goodness. I didn't realize Mint was only 50 people when they were acquired. Yeah, I used it back before it was acquired by Intuit, so I must've been a user back when you were product manager there.

Brent Tworetzky:

Thank you very much.

Holly Hester-Reilly:

You're very welcome. Do you have any interesting stories from those days? Was that your first time at a company that got acquired or had you been at one before?

Brent Tworetzky:

That wasn't my first time at a company being acquired and gosh and it's my first time at a startup and the electricity was amazing. It was also, not only was my first time seeing well-structured thought through product management, seeing this function of product management being a strategic leader of where the company goes. We really got to decide or driving the decision of what to work on and why.

It was also my first time seeing strategic product design. We had some amazing product designers there and product design in my previous experiences had all been a service function of visual design or creative directors, things like that. This was the first time where a product manager and a product designer were sitting side by side to understand the problem, how to think about user experience and information architecture and how you can actually really change someone's perspective of a product with great design principles.

We always feared at Mint, gosh, if we ever lose a member's trust, make them think we're going to lose their financial data, our company is going to go out of business, because that trust is key. We put so much time in it, time, energy and thought into how do we make this a not only a secure product from an engineering perspective, but also to make the experience secure. We think that was a really important part of building people's trust and then supporting the growth of the product that we had that ultimately led to our acquisition.

Holly Hester-Reilly:

Yeah. Do you remember any particular design decisions that helped with building trust around the financial data that you were storing?

Brent Tworetzky:

We needed to have landing pages about how secure we are, so we needed to communicate it, communicate it and for people who were anxious, we needed to have all the content out there. Here's our encryption technology and why it's top of the line, here's our policies, here's how you can contact us. All of those things were very important. We used icons of locks in lots of places.

Holly Hester-Reilly:

Yup, I remember those.

Brent Tworetzky:

We just gave this perception of security. I'm sure people do it without the actual underlying HTTPS, but we did all those things and we were always communicating it. While we tried to have both a humorous and not so serious tone in some things so that people knew, we're growing and they should expect a lot of us, but we're not a corporate stodgy engine, we were always very serious about how we described security.

Holly Hester-Reilly:

Yeah, that makes sense. Cool. Well what did you do after that?

Brent Tworetzky:

From Mint, I joined an Ed-tech company called Chegg. I actually, I really wanted to go into healthcare and I spent all this time investing and learning about health tech and I couldn't find the right company for me at the time back in 2010 that I felt it had a good user value prop and could be a scalable business in health tech at the time, at least on the consumer side.

However, health and education have a lot of similarities. Looking at health, sorry, Ed-tech at the time was starting to explode and Chegg was this very promising company that had found product market fit in a business model of helping you rent your college textbooks instead of buying them. We basically viewed this as, hey, we can save students a lot of money, what else can we do for them?

We're starting to do amazing things like creating a graph between students content classes and their academic interests. We said, well, maybe we can build a student graph from this. It can start with eCommerce, but then it can actually move into tutoring, homework help, recommendations on their college paths. This was, I think, four years into the story of Chegg, but Chegg brought in a new CEO named Dan Rosensweig, who was a storied executive from Yahoo.

They brought on this amazing Head of Product named Gib Biddle that many of your listeners must know about, who is a VP of Product at Netflix and has become a great advocate for product management. It was such an awesome opportunity to go to a missionary business that was going to do awesome things, seeing a lot of growth with a great CEO and a great head of product. That was just an awesome opportunity to learn.

Holly Hester-Reilly:

Yeah, that sounds exciting. I know a lot of our listeners are always seeking that kind of opportunity. I know some people in the product world, who listen to a lot of thinkers in the product world, struggle to actually find a position where they can really apply their principles the way they want to, and whenever someone does find that it's so exciting. Do you have any tips for listeners like that, that are trying to identify what their next role, how do I find a place that's going to be that exciting?

Brent Tworetzky:

One of the things that I've learned as both a product manager and then as a leader of the product management department is that, the head of product management sets the cultural turn on learning development and craft of product. Now, of course, they have to collaborate with their engineering partner, their design partner, the social contract, the executive team, is product going to be a strategic function or service function?

But you're going to be limited as a PM in your learning based on the thoughtfulness of your head of product in their craft of product and what they bring to the company. I would say, if you really want to learn the craft, you need to go work for someone who knows the craft. Then ideally, is in a situation of that company to implement that craft.

Those are two different things, by the way, because your head of product might say, I know what good user science is, I know what good user research and analytics is, and I know best practice of communications and collaboration, but the company may not be able to fund a user researcher or the company might say, we have one way of doing data, it's this way, we're not... et cetera, et cetera. We're not set up right now to do it the way that your product leader wants to.

That's the best combination of someone who's intentional and thoughtful and actually has the conditions to do it. For example, Chegg, Gib brought on an awesome head of user research that he had worked with at Netflix, Suzanne DuFore, and she was... She basically trained so many of us on the qualitative elements of user science. He also brought on an excellent product data leader named Lisa [inaudible], who he had also worked with to compliment on some quan side of the qual.

It was almost like this amazing learning experience across both of those things. That to me was foundational to my understanding of user science that I then brought to the companies that I've worked with since.

Holly Hester-Reilly:

Maybe tell me more about how you brought user science to more companies. What did that look like?

Brent Tworetzky:

Oh my goodness, it's been a journey doing this type of thing. Well, we've all known for a long time and it's just important and ANALEC suites have been growing in importance for a while, we've also, many of us have experienced the pain of bad data or data being hard to maintain or slow to collect. I learned just how valuable it is to collect the right data and that clean data is the most important thing and bad data is worse than no data in many situations.

From that perspective, making sure the organizations I have gone to, that we have the right data tracked and cleaned and checked as a foundation of understanding. That's something that's been in our product world for a while. The part that I think is less understood, or at least until three, five years ago, has been less understood is the qualitative side. Data tells you the what is going on, it doesn't tell you the why.

I remember using usertesting.com for the first time, I think in 2009 and saying, "Gosh, this is a really great way of understanding the why of what's going on." At Chegg, we would do focus groups. We would actually travel around the country with product managers and designers and sit behind a one-way mirror or the observation glass and watch focus groups of students and get to learn about their preferences in a well facilitated way and-

Holly Hester-Reilly:

Pardon my background noise, if listeners can hear that, I'm definitely recording from New York City

Brent Tworetzky:

Yeah, New York. To that point, Holly, I just learned how valuable it is to understand the why of product, of what's going on, the story behind the data. It empowered me or pushed me to both hire a user researcher in the companies I worked for, and be able to advocate for that position and two, train my product managers and product designers in the craft of user science to understand the what and the why.

I ended up writing a blog post about this, the product manager superpower of user science, that talks about all the tools in our toolkit, when to use them and how to use them appropriately. So much of that stems from my learning back at Chegg.

Holly Hester-Reilly:

That's awesome. What are some of the things you see in the best relationships between the product manager and the user researcher? If they're practicing user science, how do they relate? What do they do different? What are the differences between what they're doing?

Brent Tworetzky:

What we hope is, is that product managers know the basics of user research. They know what the core tools are in both understanding user intent and user behavior, and understanding it at a qualitative and a quantitative way. We hope that they understand what an interview is and what a focus group is and how to do surveys, how to do usability testing.

We hope that we train product managers and product managers practice those tools enough, so that they can know which tool should I use at the right time, how to design that without error and run it without error, and also how to make it a provocative and valuable enough test. That takes practice and experience but we hope that PMs build up that skillset.

User researchers can do all of that qual stuff. They can do the focus groups, the contextual inquiry, the one-on-one interviews, the usability testing. The combination that I really like is that a user researcher is supporting PMs and designers to do a lot of the base testing themselves, so that the user researcher is not doing that, that the PMs and designers are doing that.

It helps the user researchers and designers internalize what's going on and feel more empathy for their members and users, if they can do that. In that situation, the user researcher is an enabler. Hey, let me make sure that you're setting your test up correctly and let me brainstorm results with you. I can coach you on the first couple of times you do it, that can be really powerful.

With that in place, I love the user researcher to help us advise across product, what are the biggest problems to solve that they think user research can help solve and then tackle the meatier, more challenging user research challenge problems. For example, longitudinal studies, beta tests, diary studies, things that require more finesse, more craft of user research that comes through hundreds of hours of doing it, I prefer user researchers to focus on those more complex problems where their expertise really matters.

Holly Hester-Reilly:

Yeah, that makes a lot of sense. I love that you mentioned some of these more complex things like longitudinal and diary studies, I think it's something that I had actually heard you talk about on a podcast somewhere else and thought it was a really interesting case because I think that, in my experience, sometimes people will bring up, "Well, what if we do a diary study?" Or, "What if we do this study and it's not always clear, well, what is our reason that we want to track somebody over a period of time, over a long period of time?"

But I think that you've got some examples, like your time with weddings where it's like, ah-hah, this makes so much sense. I totally get why you would be doing a diary study or longitudinal study on this. Can you tell us a little bit more about times when that's a useful approach?

Brent Tworetzky:

Sure. These longitudinal studies and a diary study, which is a type of longitudinal study, longitudinal is tracking users over time and getting input over time, a diary study is one where you're on a regular basis getting input from a user about their experience. It's a series of scheduled check-ins and conversations throughout a user's journey as if they were writing a diary.

Many of the tools that we use, the ones that are easy to use are things that help us have information at a single point in time. When someone starts using your product, you can give them a survey, "Hey, why are you here today? What are you looking to accomplish and how can we help you?" You can also do the same thing when people leave. When somebody is exiting, you might say, "Oh, we're sorry to see you go, please help us understand how we can make the product better or help us understand why you're leaving today."

The problem is, is that what happens between that first point and that last point, sometimes it's clear and sometimes it's not. When you're unclear about what's happening in a user's mental state that gets them to start with a great intention and to end without that intention, or having changed their position of what they wanted to do and why they wanted to use your product, it's helpful to understand the triggers. Well, why do they fail at achieving their original goal, if they failed? Or why did they say they left? It's confusing why they say they left, because we think that we're providing all this value and they say, it's not enough value.

Something along the way the user uses the product experience as something that makes them change their mind or makes them just evolve in their thinking. I find the diary studies to help us understand what's going on in between. A really valuable time I used it was at an Ed-tech company called Udacity, where we have online classes. We would say, come take this online class, at the end you get a certification. The classes are around building a skill for your career, specific data science or programming skill.

People would start and say, "I'm so excited.I want to use this. I want learn the skill." Many people would then end and they would say, "I'm not getting enough value, goodbye." Somewhere in between, what happened, what triggered them to come in with all these hopes and dreams and leave and be disappointed with not being able to achieve their end goal or not feeling enough value from the product, what happened? Somewhere along the way we have to get inside their head.

If you just start at the end, they say... For example, we would heard, "Well, gosh, we're leaving because it's not enough value," we would say, "Why is that?" If you didn't continue peeling the onion there, you might say, "Oh gosh, let's lower the price, because if they're mentioning price or values and objection, let's lower the price." If you did that, then you'd say, that doesn't matter because they're not getting that value because they actually stopped putting time into it.

Well, gosh, why did they stop putting time into it? Do you have to... is it too much friction in the product? Then you'd move your roadmap, not from pricing and packaging, but you'd move it into reducing friction. Would you take your course and cut it in half, or would you find ways of simplifying your UX. But that's turns out to not be the problem either. The problem for our online course was, learning is hard.

People start with an intention of learning, they find it's cognitively challenging, and they don't get the support that they need and they don't perceive that it's valuable enough to keep sticking through the grit of learning and so they put in less time, put in less time, not seeing much progress and then, why should I be paying for it? That's what was actually happening.

The snippet of, I have great intentions at the beginning, and there's not enough value at the end, cannot be determined without actually knowing that journey. Once we understood that journey, we were able to say, "Gosh, the problem is perception of value and enough support to get through the challenging times." We restructured the pricing and packaging around that, we put in more support, and then literally every metric doubled after we launched it that way.

Holly Hester-Reilly:

Wow. It's a great story.

Brent Tworetzky:

Couldn't have figured that out without a tool like a diary study.

Holly Hester-Reilly:

Yeah. That makes sense. I think we all empathize with the part where, doing a big change, like learning something new, or a workout or health change is hard to stick with and it's hard to find companies that do it right. I'm curious, I know that you are now at Parsley Health, tell me more about how you got there and what you're doing today.

Brent Tworetzky:

Awesome. Just to maybe step forward from a couple of my steps for our listeners, after learning from Gib at product at Chegg, I had an opportunity to go to lead product at Udacity, an Ed-tech company. Then from there, moved to New York from the Bay area. I had briefly ran product at ClassPass, had the opportunity to then go run product at The Knot. Then went to run product at InVision, The Knot was 30 squad, 800 person company around consumer and then InVision was a 25 squad, 800 person SAS company.

At that point in my career, I'd moved from leading small teams, being a PM, leading a team of four or five PMs at Udacity to then leading 25, 30 person PM orgs, which is quite a different change of job. As you grow as a product leader, when you still have, even up to eight squads, you can be very much in the details of the product, but once you get above eight squads that you're leading and you actually have a layer of leaders under you, you turn into more of an operating administrator as it were.

You want to make sure you have the right people and you have onboarding processes, training processes, that you have the right strategy so that you're coordinating with the executive team to make sure you're working in the right direction. You get that you are evaluating teams correctly, that you have the org structure right. Once you get to big enough teams, you're basically an executive, unless the doer, a functional doer, other than making sure that your functional leaders are domain experts in their areas.

What I had found with as five years of leading 25, 30 squads and 300 people including engineering is that, I was basically turning into a CEO COO that can... an operating leader for a large organization, I was figuring out processes, directions, strategy, people, to set everyone up for success so that this big machine of people was as successful as they could be as individuals and the net impact for the company and of course for our users.

Abstracting those principles of setting this machine up for success, I was interested in saying, "Well, gosh, how can I apply this thinking to make a company successful?" When you're a product leader and you're collaborating great with your head of engineering, and your head of design, you can make that machine, that ship work really well, but some of the things are outside of your control, how well do you work with marketing? How well do you work with finance? How well do you work with sales, can still be many of the challenges that product people face.

My house is in order, but if I'm not on the same wavelength as marketing, and we're not collaborating well together, it can still be really hard. Or, if I don't know how the whole company works, am I actually solving the most important problems for the company? What I've tried to do is actually take those principles and said, how can we run a company with these product principles this way? How can we ensure that the company is set up for success, the company is working on the most important problems and has clear direction?

The company has the right people with the right context set up and are motivated and have good career paths, and how can we make sure that the company has the right processes of clear senses of ownership, decision-making and how we do meetings, et cetera or how we use data, et cetera, so that the whole company is working in the same direction with clarity, focus, and energy. That's been, I'd say, it feels 80% the same to be the COO of a company, ensuring that the company is operating well as being the head of product and ensuring the product and design and engineering works well.

Holly Hester-Reilly:

That's so fascinating. I'm super interested to hear more about it. I've always had this perspective on how a company runs that. I tie it back to my chemical engineering days. I think about the way that we would set up process systems and control systems to make sure that things are running in the right direction, reactions are going the right way, but there's a control mechanism that if something gets out of control, this happens and then this happens and you're finessing the whole system to make it create the end product. I've always thought that companies are like that too. I'm curious, what are some of the things that you look for? Have you got your own philosophy of principles that you look for in a company that's operating well, and what do those look like?

Brent Tworetzky:

I use a similar metaphor to you Holly, which is, you're thinking about how do I make sure the whole organization works well? I think of a company as the product, the users of the product are the employees, how do I make sure that the product is successful and the users are happy? Which is product principles. How do you do that for a regular product? Well, you have KPIs for the product and the users and the product, and you also measure the satisfaction of those users. You set their expectations well when they start using a product, and you do user training as it were, user expectation setting, but you collect user feedback along the way.

You can do the same thing with the company. I use Culture Amp to get engagement scores about how people are feeling, their net promoter score as it were. We said performance expectations for the company, how well the company is working in its processes and its outputs, and ultimately its outcomes. We can measure to see how well that's all doing. The same principles apply. Taking a step back, applying some of this thinking, what are the elements of measuring the operating effectiveness of a company almost through a product lens is... I used these three major areas.

First is that, I evaluate the company's sense of direction, which is almost a product lens strategy. I think, does the company have a clear mission of where it wants to go and problems that it wants to solve? Does it have a clear strategy of how it's going to get there and do... Is that something that's well understood that people get and believe in, and does it have clear goals of what people should be working on to achieve that strategy in service of that mission? This whole direction area, something... just like we need it in any particular working squad or for the product organization, the company needs it.

Everybody in the company needs to see and understand this so everyone in the company goes in the right direction. Second, we need to make sure our people are set up for success. Just like in a squad, you need roles, responsibilities to be clear. In the company we need to have the right people set up for success, so evaluating your hiring processes, are we hiring against competencies? Are we hiring the right people who feel set up for success when they come in? Are you doing great career development so that you're growing your people? Then, are we setting up engagement so that people are meeting each other and feel connected as a culture?

We as PMs, often feel like we need to do all that stuff for our squads, we need to make sure everyone feels set up for success, that the designer and the engineering manager and the engineers and the user researcher know their role and feel that they can trust each other. How do you build that for the whole company? Then lastly, we've talked about direction, we've talked about people, the third area is process. Do we have clear, understandable, lightweight processes or appropriately lightweight processes so that the company works well?

How do we make decisions is a great example. How do we do our one-on-ones? Are they useful and effective? How do we use data and how do we have a decision-making framework? Do we use DACIs or do we use RACIs for roles? All these different acronyms that you could look up. Everything that applies for a successful, effective, high-performing product and engineering team, applies to the whole company that way.

Holly Hester-Reilly:

Yeah. That is amazing. I'm curious to hear, let's go into that last part in particular, because I think, especially in tech companies, we often encounter people who have a resistance to process just on... They hear the word and they're like, "No, don't bring us process." I'm curious, what do you do if you are looking at the processes of a company and you say, actually, we need to make some changes here, how do you go about bringing those changes in a way that people are hopefully excited, if not, at least willing participants in?

Brent Tworetzky:

That's a great question, because the process can be a very scary word and many processes are done poorly. Folks are thinking, "Oh, just another thing. Not only do I have to do another thing, but I also have to change what I'm doing." It's cognitively exertive to go through that kind of change. I like enabling processes that provide people clarity, focus, [inaudible], getting rid of ambiguity.

We figure out like, what does it take for the company to run? Does the company have clear goals? Does it have a way of people setting... of contributing to those goals and can they see how they're doing towards those goals? That's a very fundamental part and there's a process to actually collect to that, establish that and collect that. In the work that they're doing, is it clear how they do their job? Sometimes it's defined, sometimes it's not defined.

For example, in a startup, one squad just figures out how to do in its own way, like here's how we do sprint planning and here's how we do retros, and here's how we measure our success, but as soon as you have three or four of them, if they're all going in a different way, the company slows down. You look and say, gosh, what's slowing people down? How do we... What's inconsistent across the company and should we take those things and make them consistent, repeatable, clear, and understandable, et cetera?

I look for, what's slowing the company down and sometimes there's a process there, but it's too heavy and I want to take it in and slim it down, sometimes it's an inappropriate process and sometimes that you just need to remove it and sometimes it's missing something that you need to add. For example, as someone who has been in companies that have gone from not having a decision-making framework to having a decision making framework, it adds a process that saves so much time.

There's a tool called the DACI, decider, approver, contributor, informed. It basically says on a decision, who... Sorry, I think D is the driver, who's actually going to force us to get to the answer? Who's going to be approver? Who needs to be the recommender or the contributor and have a voice? Then, who just needs to know about it? So many times, if a company doesn't have a tool like that, they struggle to make decisions. They don't document them. They're spinning for a long time. They will change their mind later on, forget the decision they made, or someone senior comes into the room and suggest something different and the team and the company feels like they have to just go back on what they've done before.

That is such a waste of time. A tool that says, here's how we make decisions, we document them, it's clear what the roles are and we have reserved the right to change things in the future, but at least we've always documented why we got here so that we have clarity around that. I've seen it save just so much time and pain by adding in a little process like that, that then can help the entire company move faster in the future.

Holly Hester-Reilly:

Yeah. I'm curious about this documentation element, because I think that's often something that varies a lot from culture to culture at different companies. Some places you've got these massive well-maintained internal wikis, or sometimes it's sort of a series of tons of Google Docs that you have to get the right invite too, to find it and somebody needs to tell you, "Oh, there's one that exists for this thing." How do you approach that? How does your company handle that in a way that's the right level of getting value from it and maintaining effort?

Brent Tworetzky:

Oh, I don't think I have the magical answer to this. I don't think there is a magical answer. I remember working with my awesome CTO at InVision and we did an audit saying, gosh, we're using JIRA and Confluence over here, and we're using InVision for design documentation over there, we're using Google Docs over here, we might be using Asana for something else, things are all over the place, how do we make life simpler?

We evaluated all the different ways we could do this. We could keep different systems. We could consolidate around one or two systems, which of those would it be? There are pros and cons of going on full Wiki versus full Google Docs. Some are better on search and some are better on discovery, some are better on mental models. I don't think you can get to a perfect answer. Even what works for you today is going to be different for you three months, six months, 12 months from now.

However, we did agree that having fewer systems is better than having more. If you're using Clubhouse and JIRA and Confluence and Notion, that might be too much. We also agreed it is helpful to set expectations of what goes where, and train new people in that so that people can serve themselves when they come in, as opposed to constantly having to ask for help. Those things tended to work pretty well for us and helped to reduce the chaos in this world.

Whenever I go into a new organization, I don't feel dogmatic that we need to be using Dropbox over Google. I'm sure some people have very strong opinions on that, and there are some cases, maybe security or scalability, or some applications built on top of that why someone might have a strong opinion. From my perspective, I don't, as long as it is useful for people, the costs are appropriate, the usability is good and it's flexible enough to adapt as we change.

Gosh, one of the worst things is your org structure changes and then you have things all in the wrong place and then you have to recreate it all or someone has to go through and migrate things, move things, that can be so painful.

Holly Hester-Reilly:

Yeah. You mentioned something just there, which is your org structure changing. How often have you been through reorganizations at the companies you've been at? What have those looked like?

Brent Tworetzky:

I've been through several. Holly, I recall even in New York Shadow Stock, right? Which has been through-

Holly Hester-Reilly:

Yes.

Brent Tworetzky:

... more than [crosstalk] New York itself.

Holly Hester-Reilly:

I went to quite a few there. I went to quite a few at MediaMath as well, so I've been through several too. Yeah.

Brent Tworetzky:

They can be very useful when they... Let's take a step back. What is the purpose of an organization? The organization structure is there so that theoretically the organization is best set up to achieve its goals. Ideally, you have dedicated people who are great at their jobs, set up for success and in their units of work, they can be successful and relatively independent that, that can make an organization move quickly.

It's great the [inaudible] mindset to push autonomy into an organization. However, as we all know from products, oftentimes your product experience mirrors your org structure. If you have a marketplace where you have buyers and sellers and the organization is built that way, then the experiences tend to be pretty different and struggle to interact with one another. If you put buyers and sellers into one area, then they tend to be a more type experience, although not as nice and polished on either user type.

There are pros and cons for structure in your organization. In product, that's an example of, do we combine two-sided marketplaces? Does mobile go inside web squad or does mobile go separately? In general, do you consolidate decision-making or do you provide autonomy and distribute things? Organizations will change over time based on what they need. However, I think changing it too often is tremendously disruptive to a company.

When you change, there are oftentimes, sometimes winners and losers or perceived winners or losers, so org structure changes can actually result in churn on actually people leaving the company. There's a process change of people learning new things, there's relationship changes, it's costly for an organization. However, sometimes your organization needs to do it, when you need to do it, it's got to be tremendously well thought through in terms of how is this going to affect my people, are my people going to feel safe and supported and set up for success?

You got to get input from your people, but without freaking everyone out that we're going to make an org change again. That's an art of, how do you get input without letting everyone know an org change is going to happen now. I've seen it done very well. I've seen it done poorly, but the best practices of, don't do it that often, know when you need to do it and do it intentionally, especially with [inaudible] and thinking of your people, gets you the best result you can.

Gosh, but I've heard of some companies that reorg every year, that's tremendously painful for people. I've heard of organizations, when they're in hyper scale have to reorg every six months. I can understand that, it's just you need-

Holly Hester-Reilly:

That's how we lived through when I was at MediaMath, was in one of those periods where, it was high growth and we reorged every six months for three or four times, I guess.

Brent Tworetzky:

It's painful, but sometimes it's also the right thing to do. You can't always know and predict or bet that you're going to double every six months for the next 24 months. If you... simply, just like you can't design your architecture that is going to assume the best case possible, because it's expensive to design assuming the upside case 12 quarters in a row. Sometimes you need to be more short-term thinking so that it's less expensive and provides you downside protection in case things don't go the way that you want them to go.

However, sometimes in that environment you hire people who know it's going to be like this and it's going to be... there's a good reason why we are reorging, but gosh, it's still hard. We know for example that the more someone changes their manager, the more likely it is they're going to leave the company, especially within the first year. There are real costs of reorgs, of people having their managers move around them and then, they don't feel supported, they don't feel safe, they worry about their future and they go somewhere else that they think is going to be more stable.

Holly Hester-Reilly:

Yeah. Is employee retention a thing that you think a lot about in the leadership roles that you've had?

Brent Tworetzky:

A hundred percent. We are our people and people make the difference of, do we enjoy the work that we do? As humans are we getting that emotional resonance of enjoying the people we're working with and being happy every day, or feeling like we're on the same team? Then, and feeling like you're with the right people increases the performance of a company. Well established teams with stability and psychological safety that do not change team members that often have been reported and researched to have the highest performance.

We want high performing organizations, has to have high-performing teams. You want to enjoy being at an organization, you need to also have people who you connect with. How do you keep those people? There's many things that we can talk about about inspiring employees and people to love the work that they do. There's a great book called Drive that I love that talks about people need a sense of autonomy, opportunity for mastery and great sense of purpose. There's other research that says people really need to love their manager et cetera, et cetera.

We need to measure these things. We need to figure out how are people doing? Then we need to have people feel like they're being heard and listened to, and we need to take action, whether you're managing one person, you're managing an apartment, you're managing a company those principles still apply.

Holly Hester-Reilly:

Yeah. I love what you just said because in some of my best experiences or companies where I felt the most supported, that was one of the key things, was just that I could see they were very transparent about the fact that they were measuring these things and they were taking action. Just knowing that the company is trying to make it better and seeing that action and seeing the progress six months later when they get up in front of the company and say, here's how the stats are looking now, made a big difference to me as an employee. Yeah, I can definitely see that happening.

One other thing that comes to mind is that, you've worked in a lot of different domains. You've listed off several things along the way there, you've been in education, you're doing healthcare now, you did design and I don't know what you call the not weddings, I guess.

Brent Tworetzky:

Relationships. Relationships.

Holly Hester-Reilly:

Relationships, yes. Having been in all these different domains, what is your perspective on the value of the perennial question I often get when I'm talking to new hiring managers is, do I find somebody who's got the domain experience or do I find someone who's really great at their product? What is your perspective on domain, the importance of knowing the domain?

Brent Tworetzky:

Great question, and one that we tussle over all the time. I actually think about it, there's two dimensions, there's the industry domain, so you've talked about, oftentimes it's consumer versus enterprise, and then even within that consumer it's all these different areas that we talked about. But I also think about the types, on the product side, the types of products you've worked on. Growth is different than community is different than content and media is different than workflow tools is different than gaming is different than security.

I'd say, there are some roles where experience with either the particular use cases or the particular industry is really important. Very oftentimes that is, you don't need both of those things and you might not even need either of those things. For example at InVision, which is design software as a service, workflow software and tooling, I needed for my enterprise, PM's who were working on enterprise tools to help us scale and work with enterprise technologies, such as identity management. I actually needed people who had experienced in that area.

Enterprise security was an area that was very important and other parts of the product of like, growth, tooling, et cetera, but the PMs didn't need to have experience in design tools. It helped of course, but it wasn't required. It was also helpful, but not required to have domain experience in that area if they were a good generalist. There was enough support in the squad and the other PMs to get the work done.

Sometimes it matters, sometimes it doesn't, knowing that difference is really important. Someone who's just a great generalist PM is so hard to find that I would genuinely take a great generalist PM with active domain experience than take a less qualified PM with the domain experience, because VPMs will learn that domain quickly.

Holly Hester-Reilly:

Yeah, absolutely. Well, I know we're almost out of time. I always like to wrap up with, if you have any final advice that you would give to aspiring leaders, whether product leaders or people looking to move from product leadership to operations, what would you say to them?

Brent Tworetzky:

Oh my goodness. So many people have said these types of things better than I can but, if you have a passion for service, for help making your people feel set up for success and your organization set up for success and you have to have that humility leadership outside product in a broader space really needs you. If you think that you want to get to a more senior level, because it strokes your ego or it's something you've always thought you needed to do, but it's not authentic to you to actually serve, then you're not going to enjoy it.

The higher you go in an organization, the more stressful it is. I don't know if this is actually true, but I remember a CEO I used to work for, a great CEO said to me, "Half the CEOs of the Fortune 500 companies are on anti-anxiety medication." I don't know if that's true, but I could believe it because the higher you go, the more stressful the job. The higher you go, the more likely it is that there's something really challenging in your organization. We just need one really bad thing to happen for you to be stressed out.

If you manage one person, having that one person be happy is easier. If you have an organization of a thousand people and one person's really unhappy, that's still becomes your problem as the leader of that organization. You just need to be able to deal with more anxiety, more pressure, more stress. You need to be going eyes open, knowing that and enjoy that servant leadership, and you want to be able to take that on, to really thrive in a role like that.

Holly Hester-Reilly:

Yeah.

Brent Tworetzky:

A lot of people don't realize, the higher you go, the more stressful it is. The pay can go up, but it actually doesn't go up that much in many cases, but the stress goes up a heck of a lot more.

Holly Hester-Reilly:

Yeah. Awesome. This has been so much fun. I'm so happy to have talked to you today. If people want to find you, where can they find you?

Brent Tworetzky:

They can find me on LinkedIn, they can find me on Twitter. I don't tweet that much. I have a bunch of product articles on product leadership and building a great product team and organization on Medium, so check me out in any of those places.

Holly Hester-Reilly:

Awesome. All right. Well, thank you so much Brent, it's been a pleasure. Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and products leaders how to use the product science methods to discover the strongest product opportunities and lay the foundations for high growth products, teams and businesses. Learn more at h2rproductscience.com.

Enjoying this episode? Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you love the show, a rating or a review would be greatly appreciated. Thank you.