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.

It may or may not be appropriate. Unless you understand the why you're doing it, it's not likely that you'll understand how to do it. I was talking to someone yesterday who said to me-- no, I'm sorry, two days ago-- said to me earlier in his career, he had to convince people to go from waterfall to agile. Now he has to convince people to go from agile to agile, just to get it, to understand. That's a real problem.

Agile is just a tool in the toolkit because I'm trying to build some product. Agile or agile methodology is just one of the tools in the toolkit. You have to pick the right one and if you don't know what they're for, it's hard to pick. At home, I'm the repair guy, and I’ve got a bunch of different kinds of wrenches. Sometimes, you use a box wrench, sometimes you use an adjustable wrench, there's different times you use a different wrench because I have a different problem to solve. I got a bunch of different kinds of saws. It's the same. I’ve got a table saw, I've got a handsaw, I've got a jigsaw, I've got a miter saw. You have to use the right tool for the right problem. If you use the right tool, things tend to go really well. If you don't, you might lose a finger.

Ross:

I like that, I like that. The other thing is when you say they're going from agile to agile, it's almost like they're going from Agile with a capital ‘A’, the religion to agile with a small a, actually being agile. [chuckles]

David:

That’s right, that’s right, yes, there you go.

Ross:

They're just going from uppercase to lowercase agile, but as long as they're going there, that's great. What else are you working with at the moment-- you've been around a while-- what is it that you're seeing in the marketplace, or what you're working with that's really exciting you at the moment?

David:

This is the same thing as before. I'm very engaged in how technology products are changing things. It's the markets that are still nascent, that still have opportunities. I mentioned the company that's doing pharma clinical research. I'm interested in the application of that because doing that well means that drug trials can get done faster, and more people can get healthier faster. That's more about the outcome than about the product.

From a product standpoint, BaseCamp talked about their methodology, which is another form of agile. I'm sure. It's called Shape Up. I think it's very interesting for B2B businesses to think about that, and to think about looking at Shape Up, but just-- it's another form of agile, but it's agile when, once again, it’s the right tool for the right job, It's agile that might be more for a B2B thing. I think it's very interesting. There's a Spotify model, but it's not bad cause it's old, but it's interesting. It's interesting to do it. From a technology standpoint, there's a hundred things that are going on that are interesting. Of course, there's the data science, big data kind of thing, that's been going on for the last few years.

I think that embedded computing in a variety of different places is interesting, what Tesla is doing with constant updates of their vehicles. Making a car into a computer with wheels is a great example of the Andreeson thought of “Software is eating the world,” which you probably said now seven or eight years ago. Software continues to eat the world and eat the world in more interesting ways. There's a bunch about Tesla that I actually don't like, but their ability to update the car and create new facilities in the car is just very interesting. If you've had one, what they're doing is super interesting there, just because almost every week or two, it's like having a new car that's better. That's really interesting, but it's not just about that vehicle. It's about people doing that constantly with every device. I've got like all the smart thermostats, smart sprinkler controllers, things that allow that thing.

The integration of those devices around the home and around other places, and the facilities they provide is great. For instance, I've got smart sprinklers and smart thermostat and I've got a whole house fan that cools the house. I live in Southern California, where the nights tend to be cool and the days are hot. The house might be hot but I can integrate the smart thermostat with a smart switch on my whole house fan and have those work together and cool my house much more efficiently with consumer-level programming. Those kinds of facilities and integration-- I think it's very revolutionary and it is going to continue to be revolutionary. I think that's just interesting.

Ross:

Yes. I think it's an amazing time to be doing things. You're talking about your mom earlier and I'm like, I sometimes say to her, “Mom, we're living in the future.” If you think about things like FaceTime that we just take it for granted. I just love it. I think being involved in product right now is such an exciting time, and there just seem to be so many, so many exciting things coming down the line and amazing tools. I think about great road-mapping software, like product plan.

There's so many tools that I've talked to. Now, there's so many vendors I talked to, for example. There's this great company in Europe that is doing prioritization software just for product managers. It's just so exciting to be a part of it.

David, I want to be respectful of your time. Is there anywhere that people who'd like to know more about you and your company can go? Are you active on LinkedIn? Where would people go?

David:

Well, people can find me on LinkedIn. David Subar, S-U-B-A-R. We have a company website, Interna, which is interna.com. I am glad to have people reach out to me. I tell people regularly-- we have a consulting practice and we do this for a living-- but if someone has a question, they just want to ask a question, want to spend a few minutes on the phone, they should just hit me up on LinkedIn. When you do it, like, “Hey, heard you on a podcast and just have a couple of questions. Can you spend a few minutes with me on the phone?” Glad to do it, 100%, all the time. I'm also on the board of the LA CTO Forum, which is the kind of same thing. It's not-for-profit, where we just try to make the community better. Glad to just-- I'm just glad to be helpful. People should check me out on LinkedIn and on our website. You can hit me up there and I’m glad to help.

Ross:

For anyone listening to this, I've loved the conversations. I'd love this conversation on the podcast, but I've also really loved the conversations I've had with David that have been on outside of this podcast. I think that's incredibly generous of you, David. I hope someone takes you up on that. I hope you've really enjoyed this conversation and I really want to thank you for having been with us today.

David:

Great. Well, thank you for having me. Thank you for having me.

Ross:

Thanks, David. Speak to you soon. Hope you'll come back on the podcast sometime.

David:

I’m glad to.

Ross:

You have just listened to The Product Coach Podcast with me, Ross Webb. A huge thank you to David Subar for joining me on what was a great discussion about a topic I really, really think a lot about. I really enjoyed the examples around agile and waterfall and learned about the dynamic between engineering and product from his perspective. Check out our show notes and links, and our site, theproduct.coach/blog. Remember to subscribe to our podcasts on iTunes or Google Play. If you have any questions, please feel free to drop you an email at ross@theproduct.coach. I look forward to hearing from you and I look forward to having you with us next time on The Product Coach Podcast. Bye for now.