The Blog

Schedule a Consultation

Have you read our blog and still have questions? We offer no-cost consultations to portfolio firms and organizations seeking further advice or assistance in strengthening and growing their Product and Tech teams. 

Sign up now to schedule your session with one of our expert principals. 

Recent Posts
What's next?

Interna principals present at events worldwide. We send out a monthly newsletter with information on where to find us next and how to stream our talks to wherever you are. Our newsletter is filled with additional tips and tricks for executive leadership and the latest stories in global tech news.

 

Stay up-to-date by subscribing to our newsletter using the button below.  

How Product Can Work Best with Tech



David's notes:

Product Management and Engineering operate better when they function together. I had the opportunity to join Ross Webb on an episode of The Product Coach where we discuss how to focus the efforts of PM and Engineering on a common goal, and what that goal should be.

Transcript:

Ross Webb:

Welcome to The Product Coach Podcast. I am Ross Webb. Today, we have David Subar with us. David brings a really interesting perspective to Product, as he often straddles the line between Product and Engineering. He has had a fascinating career and some of the highlights of today's podcast are the importance of why, and why context is so important for teams. He's going to tell us also about learning to negotiate the relationship between Engineering and Product. He also taught me about when going back to waterfall actually makes sense. David's a great guy. I think you're really going to enjoy this one. David, thanks so much for joining us.


David Subar:

Thank you. Glad to be here.


Ross:

David, why don't you tell us a little bit about your history? I know you've been around the block. I'd love for the audience to hear a little bit more about where you come from and your experience and a little bit of what you'd like to share with them today.


David:

Sure. I'm glad to. I started my career doing Research and Development in AI and machine learning at a government think-tank in DC. I was congenitally born a nerd, and had been a developer since I was 12. I was really excited about doing research development in AI and ML; and after doing it for a few years, I found it really frustrating.


Ross:

Why is that?


David:

The reason it was frustrating was that I was developing technology. If it was good, we wrote a paper and maybe presented at a conference, and maybe 200 people listened and then nothing happened. After doing it for a little bit, I wanted to build technology that did something, that made a difference. Doing research wasn't doing that for me. I switched to building applications that people use. First, I started out at an AI tools company, and then I worked with a different company. I started out as an engineer, and then took more and more senior positions because I wanted to get to the place where I was able to make sure we were building something that mattered to people, that mattered to a market.


And so, I got larger and larger engineer roles. Then, I eventually became CTO of some companies. I had a game startup that I ran for a while. Then after being CTO, I took on Product responsibility as well, because I wanted to be on that apex where we could imagine-- we understand the market, understand the users and imagine what they needed, release something and get feedback, and make it better and better.


Being able to-- being part of Product and being part of Engineering, and being at the apex of those, allowed me to do that, to do the opposite of what I was doing in research: building products that matter to people.


Ross:

That's really interesting because that's obviously got a very, very strong technical-- as you said, I think you said you're congenitally born a nerd.


David:

[laughing] Yes.


Ross:

I think that is what you said, that's cool. I've never heard that. That's great. Then you also got into Product, so you obviously have a really strong technical expertise and also, let's say, a love of products and building products. How did you end up moving forward? Did you end up gravitating more towards the technical side, the Product side? How did that evolve?


David:

I gravitated toward the Product side. I started in the technical side, but I had decreasing levels of frustration as I was able to have more and more impact on the what and not just the how. Now, clearly, those things are interrelated, they're interlaced. I always cared about “why were we doing this?” I actually got- I had a guy that I worked for early in my career and he said to me, “You need to stop asking questions about why we're doing it and who are we doing this for, and just do the thing we need to get done then.” I looked at him, and I thought “I get the instruction, but I'm not sure that's really great.” And I think he was wrong!


There are three ways to do anything from an Engineering standpoint. Unless you have the context, you're not likely to consistently pick the right one, but because I was so focused on wanting to figure out who we serve and how we serve them, that was my drive to move closer and closer to Product and start managing Product to do those kinds of things. While I'm still congenitally a nerd, it's the nature of being genetically wired in some way-- the thing I care about is “Did it matter? Can I tell my mom? Will she get it?” For whatever reason, that's the way I'm driven.


Ross:

Cool. I love what you've just said there, because hopefully my mom actually listens to this. She's now also at a wonderful age of nearly 78. She is able to talk to people about agile project management. I'm incredibly blessed there. What is it that you do now and how do you explain it to your mom?


David:

Yes. For the last six years, I've been working with several companies simultaneously helping them on Product Management and Engineering, and how to make those groups more effective. How do you build fast, release fast, get market feedback-- that kind of thing-- and do it again and again? How do you organize the teams? What do our architectures look like, how do you know if you're doing well? That's what I do. Right now I'm working with four different companies to help them do that. One is a SaaS for pharmaceuticals to help them in the clinical trials’ sites to create drug products better and faster. One is a celebrity in Los Angeles whom I can't talk about, who is about to release a new consumer-facing site with both ecommerce and events attached to it. That should be pretty interesting.


There's another SaaS service for the entertainment industry that I'm working with. There's a couple others. I'm sorry, there's five. I think I said four before, that I'm working with.

I want product managers and engineers to know who they serve and how to serve them better, and I am meta from that. I think about, “How do product managers and engineers get better at doing that?” My service is making those groups better. That not only means the company is more successful in producing a product that serves the market, but the engineers and the product managers, those groups are better; and the tendency is that the people in those groups tend to be happier.


Ross:

That's really interesting. One of the things that I've encountered-- I was having a conversation this week with a product owner that I've been coaching for a while-- one of the things that I said to him is, one of the reasons I think things weren't going smoothly is he really didn't have a tech lead that he trusted and had a real emotional trust that things were going to get done. For example, when the tech lead said it’s going to take three months, they hadn’t built up to that level of trust that they knew that that was going to happen. I think back to some of the most successful products that we have launched, and I always had a bit of what I like to think of as positive tension with my tech leads, where I want everything done tomorrow., but they've got other concerns. I've got concerns around customers and users, while they've got concerns around the developers. Obviously, if we had to look at a perfect Venn diagram, there'd be a hell of a lot of cross-pollination. I always think back to a documentary I was watching about Pixar, the film studio. They were talking about how-- in their example, there were the directors who are these creative geniuses who wanted all the resources to make the most amazing thing. Then they had a producer who was, “Okay, that's great. We've only got X amount of money.”


A lot of the way I understood it was because of that creative tension, they were able to play within a certain box. It wasn't, “You've got an unlimited amount of money, make whatever you want, go crazy and come back with, I don’t know, movies like Ishtar!” If anyone remembers that. What I'd love to get from you is-- and I know this analogy falls on it’s face, and I know the tech leads are not-- let's say producers are product managers, and directors are the creative ones, technical. I don't mean to put it like that but what I'm trying to put more focus on is less about creative versus technical or financial versus creative, more about the positive, creative tension, if you will. Do you encounter that in your work with tech leads?


David:

Yes. One is... there is that tension of what can we imagine doing and what can we practically get done in a reasonable timeframe or with the people that we have? There is that tension, and there is that pull back-and-forth. In addition, I want the engineers to also care about the product and to have opinions and to be part of the process, to volunteer their opinions to the product managers. I want the reverse too, which I'll explain in a second; but at the end of the day, the product managers, the product team get to make the decision, but I want-- that tension should exist. It's much like I was-- I forget which poet I was reading about. It was an interview with this poet and he said-- It was the nature of trying to do the structured poetry, like iambic pentameter, that constraint that caused him to have a good result.


You'll hear jazz musicians say the same thing. They understand the music theory and then they deviate from it, but that construct helps them create something. It's the same with product managers and engineers, it’s that tension. Here's the thing I can imagine and here's the structure, or here are the attributes of what we can do, then do it; but I want the engineers engaged. Here are some other things we might be able to do to serve the customers or it might be that we can't do that because that's going to take three months, but I can do 90% of that in two weeks. By the way, you get this feature and I want the opposite too. I want the product managers to know something about the architecture and say, “Why are we building it that way?”


I want them engaged in each other's crafts because at the end, the two teams, Product Management and Engineering, they’re one team trying to build a product, trying to satisfy some market. That's the engagement I want. You mentioned something that’s funny that happened to me just yesterday with one of my clients that I was coaching. I was sitting with the engineers. It was two engineers. I said to them, “The fundamental problem that you guys have-- and this is with executive management-- you're not communicating well, and you've got a trust problem, and it's both ways.” That trust thing that you just talked about is critical to have this be successful. We're on the same team, serving the same people and we succeed together and fail together. By the way, of those two, let's choose to succeed.


Ross:

That's great. I'm glad you’ve also gone through such a timely thing. I'm also trying to think of an example where a product owner I was coaching used to have these business commercial-- every fortnight, every two weeks-- meetings. I remember they were going and they were pretty much representing technology and saying, “Look, the reason this is going to be delayed is ____.” I think going to a big technical explanation that honestly, how do I put it? It's not that they weren't qualified to give that discussion. It's just that if the business wanted to get into any more detail, then they would need to go, “Hey I'm going to need to get back to you on that.” I made the suggestion to them that when you go in there, why don't you go in there as teamwork? Bring them with your tech lead, go in there.


When there's a delay or something, my philosophy has always been that bad news needs to be communicated really, really quickly. If you're a team, and let's say your tech team has let you down for whatever reason-- and it could be because you miscommunicated to them and you need to take ownership for that, but regardless of that-- let's say that they have dropped the ball. It's great going in there. Also, I always wanted my product owners and my tech leads to know that, even my junior product lines, that I had their backs. If I'm going and saying, “Look, we got to miss the deadline and I’m bringing it to your attention as quickly as possible and this is why we've done it, happy to drill into the details. I've got the person here, not pointing fingers or playing the blame game or anything, but here they are, let's get into it.”


80% of the time they'll be like, “Okay, you know what, it's fine. I trust you. You guys have got it,” but I think that comes over time. You're right, there is that kind of jazz that I think of various tech leads that I've worked with over the years that I have huge amounts of affection for. Even though at the time-- I remember once moving on from a role and one guy said to me, “Ross, we've never, ever seen eye-to-eye, but I've always respected you.” I'm like, “That's awesome. That means we don't have to agree.” But you know what, when he moved into a new role, he said, “I just want to tell you, I’ve got a new role. This is what I'm doing, and this is great. It's great to see what you're doing.”


I was like, okay, what that says to me is there was a relationship there, and there was a relationship there that the guy actually felt he could communicate. It's been the other way around where I've dropped the ball and I've messed up and said things that don't make sense. A lot of the time, I used to say to this one tech lead, “Your job partly is to kind of save me from myself. I'm going to ask you for some things that will seem totally unrealistic, but I'm not aware of that. You need to make me aware of that.” A lot of that is sometimes done, let's say, behind closed doors, not in front of the team.


David:

100%.


Ross:

How has that played out in your experience?


David:

We're in violent agreement, you and I. I do three and a half things in my consulting. I'm giving you this context as it will help explain the next part.


Part one is, I'll do a deep dive-- and it's not just me, there's a few of us. We'll go in and we'll do a deep dive-- my company's called Interna, and there are a few of us. One thing we do is a deep dive into product management and engineering and say, “Here's some stuff that works well, and here's some stuff that's not working so well. Here's what you might want to do to change that.” A diagnosis and a prescription, if you will, that's one.


Two is the coaching and mentoring of CTO's and Chief Product Officers, so they can help run their groups more effectively. That's two.


Three is, we'll take interim roles, either as CTO or Chief Product Officer, to help run groups if there's not someone there. We'll help make the group better and then hire someone behind us.


Then we do a half thing, which is diligence for investors, VCs and PE firms.


Ross:

Sure.


David:

That's the context that I just told you a minute ago, about a place that I was coaching. This is another context where I'm working as the interim Chief Product Officer, and the VP of Product and the product management group all report to me on an interim basis, as well as the VP of Engineering and the engineering group. I had that exact same conversation with him.


He was presenting to me, he's new. He presented to me how he wants to change the engineering group; and there were things I just disagreed with him about. It was okay, it was fine. At the end of the presentation, I said, “We don't agree on all these things. Some things we agree on, some we disagree on. That's good. That's fine. Let's figure out who's right and who's wrong. I don't really care who's right and who's wrong. Just want to get to what's right.” His attitude was the same. It's just like-- he wasn't offended by me saying, “Here's some stuff I disagree on.” Some of it, he presented immediately to me, “Here's my thinking about it. Here's why I think my thinking is right and yours is wrong.” He immediately told me and I said, “Yes, got it. You're right.”


Sometimes, we have to go back and do something else, but it doesn't matter. We both want to have the groups be successful so if we disagree, it’s fine. How we get to a resolution is what matters. How do we get to a resolution around the creation of value and having the groups be more successful, as opposed to just arbitrary, you report to me so I'm making this call? As a matter of fact, by the way, for the record, I'd rather make as few calls as possible when I'm in that role because I want the teams to be empowered. Just as long as you're making decisions against the same set of criteria, we're good.


Ross:

I want to get some advice from you. I want to see whether there's something that you might've done differently. I recently ended up coaching a company where they did have an interim CTO. I really felt his heart was in the right place. He knew what he was talking about. He'd gone ahead and implemented agile, or gotten the company to move away from waterfall. He'd taken the head of project management, made them the product owner, taken a subject matter expert or a BA, and made him a product owner, and it failed. It failed in that the guy was there for a year and when he left, when his contract was up, the company pretty much couldn't wait to go back to waterfall; and it was really interesting. It's one of the few places where I've been that had zero interaction with customers. I remember saying, “We've got to get people talking to customers,” and being told, “That's going to be like a C-change.” As soon as the guy left, like I said, it's moved back to being waterfall. I'm not trying to say agile is the only way to do it, although I like to think that at this stage, the debate is over. It's a question of what is the best way of implementing it. Regardless, have you been through an experience like that before?


David:

Where they failed back to waterfall?


Ross:

Where someone came in and tried to say, “Hey, I'm an interim CEO and we're going to move towards product, being product-focused, and we're going to put in agile,” and then they left and pretty much everybody moved back to waterfall. They failed back as you said, yes.


David:

Yes. I've been in that situation where-- and I don't know about the particular situation you were in-- but I've been in the situation where I was brought in after that happened. Once again, I don't know about the situation you're in, what I've found is one of two patterns. Either they were going through the motions of agile and not actually aligned with the values, and what you're trying to get with the different agile methodologies or toolkits, to get to a goal.


If you're not committed to the goal, it doesn't matter. You'll fail. I've been in situations where if I've been interim Chief Product Officer, interim Chief Technology Officer, the CEO might have not actually been committed. Organizations take on the shadow of their leader. Sometimes that shadow is good. Sometimes it's not good. Sometimes it's purposeful, sometimes it's accidental, but it always happens that way. Like if you have a leader who is a CEO who is always reacting at the shiny object.


Ross:

Sure.


David:

On one hand, Kanban is great for that. On the other hand, it’s not always thinking about how to deliver value other than today's revenue number. Sometimes the team wasn't buying into it. Sometimes it's the CEO, who has a different direction. You just have to recognize that. Sometimes CEOs do that. I'm not arguing for it or against it. I have an opinion... In that case, part of the job is coaching the CEOs. Let me tell you the choice that you're making. Let me tell you the ramifications of that choice.


If that's the choice you want to make, then let's talk about that. Oftentimes, I would suggest it shouldn't be, but sometimes-- actually here's a particular example. I can't tell you the company name, but they were PE-owned. It was a client of mine, a private equity firm owned, and the private equity firm wanted to hold the company for about five years and they were getting to the end of the five years and they wanted to sell it to another private equity firm.


All the company was interested in doing, all the CEO was interested in doing was, how do I optimize for today's revenue because I have to make these revenue numbers bigger and better because in the next six months we're going to get sold. He was after shiny objects, but he was after shiny objects, well, theoretically for a good reason, because he had to get a transaction done. The attributes of agile that you would normally want, were not relevant to him. He told me that. I was like, “Okay, I get it. I don't love it, but I get it.” They played agile. They weren't really agile. He made it very clear, “We're going for a transaction and we're not going to be optimizing against speed and decrease in costs, not really against long-term value creation.”


I would have to think about that. Now, by the way there are, and I think this is important. There are few circumstances where waterfall does make more sense. If you're launching a rocket where the cost of return is really high, for sure. An augmented reality company I was working with, I was running Product and Engineering in neuroscience, and I was producing a piece of hardware as well as an operating system. Hard for hardware to be agile because of the nature of it. Usually, almost always, pick an agile methodology. There are several of them, pick the right one, but pick one.


Ross:

What else is-- help me understand that. You did describe it, but how would you explain that to the technology team? And maybe I should understand it in more detail first, but are you saying that he was like, “Instead of agile, let's stick with waterfall because in X, two years’ time, we've got this event.” Have I understood that correctly? I feel like I’ve missed something.


David:

Yes, I probably didn't explain it quite well. The event was hopefully going to be nine months. What he said was-- he didn't say, “Be waterfall.” He said, “Yes, yes, sure, do all the agile stuff, but I don't really care about epics. I don't really care about velocity. What I care about is how fast we're getting out this feature. I'm going to have another feature tomorrow and the next day I'm going to have another feature. I'm going to be constantly distracting your team because I'm only asking them to do things that increase today's revenue.”


Kanban might be perfect for that, except that there was some complexities about dependencies between cards that they were running between tasks; but the nature of running agile the proper way... what they really needed to was to run scrum or XP.


What they really needed to be was thoughtful about epic statements and what they were and how they think about them. I'll talk to you about why I think about his epic statements in a second, and value creation. Like, we're doing a bunch of cards, a bunch of user stories towards a greater goal. The CEO said, “You're thinking way too far in the future. I'm thinking I need to get numbers better today because we're selling this thing in six-to-nine months. I need to see a trend line. I've going to ask you to do all kinds of stuff that's really ugly.” The nature of that is that the product focus, the user-level focus of serving a customer and creating value for a market from a cultural standpoint, that was all disruptive.


I was there to help them get to the next goal. I hired someone behind me to take over after me. That's typically when we're doing these interim roles. Part of the thing we do is we interview and find someone who can take the group after we leave to get it to the next step, but the CEO didn't care about any of that. He cared about getting to a transaction. After the transaction, everything could fall apart. “I don't care because guess what? We all made money.” Now, I don't love that, but that was what he made clear. That organization, when we left after the transaction, is going to fall apart in the same way that you talk about it, we'll go to some other methodology. It might be waterfall. It might be some agile-like thing, but it won't be culturally aligned to creating long-term value or creating value because that wasn’t what it was being built for. It was being built for the sprint, literally.


Ross:

I get that. I really like that example; because essentially, you're saying hey, there's one very near-term event in nine months happening, I don't really care. I just needed it happening this way. I had a really lovely chat with Jeff Gothelf a couple of weeks ago, who's a very well-established thought leader in the agile space and using customer experience. He said, “Really, there's-- we can talk about--" I’m massively paraphrasing this, Jeff. If you listen, I apologize, but really what he was saying and my understanding was, “We can call it agile. We can call it waterfall, but there's really got to be four things.


The team needs to be ready to be small in order to be able to be nimble. I'm trying to avoid using the word agile. The team needs to be focused around outcomes rather than outputs. It sounds like the CEO you're talking about wanted a specific outcome and everything was focused around that. You mentioned-- The other one I'm going to mention, which I think is really important, is the team needed to be empowered around making decisions to get them there. It sounds like with the objective that you had, the teams probably were relatively small if they needed to be nimble to get there that quickly. It sounds like they were empowered, it sounds like if they went back to you or the CEO, and said, "Look, you want this result, we want to take this decision to get there and that's why, because it's incredibly clear what it is you want.” Do you think I've understood it correctly trying to apply some of those terms?


David:

You have, except the team wasn't empowered. The team had to follow like, "Oh, I need this today, I need that today. I need this today." Everyday was something different to get to because what the CEO was hearing from the private equity market was changing, was trying to adapt to that. Something would happen with a particular customer of theirs that might either endanger our revenue, or a potential customer that might create revenue. Because it was so short-term focus, it was a bunch; but it was purposeful, if you will. After the transaction, the buyer might have a little rebuilding to do to address the culture. Everything you said was right, except that they weren't that empowered. It was a bunch of small tactical things back-to-back.


Ross:

I get that. It sounds like it mirrors the example I gave you, where as soon as the person who wanted a specific outcome has achieved that, if the teams aren't aligned and empowered, it's just going to go back to, as you said, “agile-like” or something like that, right?


David:

That's right. Exactly. By the way, the team was frustrated in this example. I explained to them, like, "Here's what's going on, here's why it's going on. There's going to be a cost to pay for that.” The answer is, “Yes, there is." Everybody at least had transparency into why. At the end, the team was going to pay the cost of having to rebuild again.


Ross:

Like I said, that's a really great example. I really like the fact that what you've also come back with is, "Hey, if we're building the rocket, if we want to go to Mars, two weeks sprints aren't necessarily the way to go. There's some fundamental things that you have to do first, and get right to the nth degree, before we can look at the next part.”


David:

Only because the cost of return and the cost of release on a rocket is so high. In software, it’s really low. You can iterate really quickly and you need to build processes, and tooling, and culture around that on the product side and the engineering side. I can think of one example in my career, where I suggested that someone be waterfall. Since I bought the agile religion, the conversations I have is which flavor of agile do you need. And that applies to everyone, except for that one particular case.


Ross:

It wasn't SpaceX, was it?


David:

It was not SpaceX.


Ross:

[laughs] I'm just kidding. I agree with you. I think last month I was in Denmark, where that company that I was talking to had Europe's largest implementation of SAFe. It was really interesting that, before I went and actually saw how that implemented it, I was never a SAFe fan.


It always felt to me really all you're doing is, I think, as you said, like agile-like. All you're doing is taking, let's say six months, and you're just dividing it into two weeks and putting a bit of extra time that people can do things and then deleting them. Then when I saw how complicated-- and it was financial trading software-- when I saw how complicated it was, it ended up making a hell of a lot more sense to me going, "Hey, you know what, I think there is some potential in SAFe. I think there are some things."


Whereas a lot of people I talked to are agile coaches, their noses are specific flavors. I think it becomes a religion after a while, to be honest. I think it becomes, going back 15 years or so, the PC versus the Mac wars: is it agile, is it Kanban, is it scrum? I think a lot of them don't have experience. One of the questions that I like to ask when I'd join an organization when coaching is-- almost always, in fact, pretty much always-- I can't think of an exception here, they'll come to me and they'll talk about, “We do two-week sprints.” My first question is always going to be, “Why do we do two-week sprints?” Not a lot of people have got the experience to say things like, “Where is three weeks sometimes better?”


To me, three weeks sometimes is better because you've got a new team and they're gellin; instead, they need a bit of extra time to start, they’re getting the head around documentation. Maybe over time, let's say, we can finesse it a little bit more. Sometimes in the beginning, they're really just gelling and getting to know each other. Sometimes, one-week sprints work. In my experience, it works when I've had very mature 10-year-old products that really need a lot of continual tweaking, we're not adding huge amounts of features.


At least to have the experience to be able to talk about where it's worked, and where it hasn't worked. A lot of people-- and I'm not separating myself from the-- but a lot of people will say, "Two weeks, that's just what we do. We did the course. It's two weeks, man." I struggle with the thinking where people have really gotten their head around it or they haven't. Do you come across that as well in your coaching?


David:

All the time, all the time. Sometimes people play agile as opposed to being agile. They understand some of the ceremonies, maybe some of the information radiators but they don't understand the why. I'm one who believes in start with the formalism and exercise the formalism, but understand why there's the formalism. Then, part of the formalism in all of these is some kind of retro, modify it for what you need. In your example of sprint lengths, I completely agree with you that two weeks is an arbitrary recommendation of sprint lengths, but you need to fit it to your situation if you're doing Scrum or XP.