Andrew: I always loved technology. I come from Eastern Europe and I remember you know, things weren't really that great back when I was a kid there, but a cousin of mine he brought a game, it was a duck hunting game. You could shoot ducks basically and you moved kind of left and right and the guy had like four positions and the ducks had only 10 positions. It was really my first technical thing that I ever saw but it was really amazing for me. It's odd that I remember that, I guess, but that was the first exposure to technology per se. I loved the idea.
My grandfather and my parents were into kind of building things. My Dad was a civil engineer. My grandfather made various things using wood. He was the “wheel man” as he was called in that village. So I loved building things and I was exposed to this technology and I loved it. So ever since then I always liked to tinker with it, do things with it.
My brother was into technology and he brought home, I remember one summer, he brought home Amiga. I don't know if people still know that but it use to be a computer platform and system. I use to render things with it and program and you know, I guess it just kept snowballing into that. Then I went to university for cognitive science, another one of my interests, psychology and computer science. That was all great and good, but I guess I didn't like the pace of it. I didn't like academia and my inability to be flexible about what I learned and the pace of my learning. I essentially dropped out and that's when I got a job as, really a project manager in technology.
Suzanne: Where are we in the timeline here? How old are you at this point?
Andrew: So I was 18, I dropped out and basically, joined a startup. A hosting company had created a kind of a web development company and I joined them as the lead developer/project manager and tried to get…build products…even at that point I didn't know, it wasn't defined as such but basically it was products. So that was 1998, I think, when all that went down.
As you know, the market kind of crashed a year later and that was kind of the great reset. I had a good job at the time actually. They were paying me an insane amount of money for my age and experience. I was so, kind of, I guess arrogant or gung ho, I quit on my own accord, even though the market's crashed and no one has jobs in tech at that point, they still have me. They fired like half the people there or let go rather. I was just really, I was like I'm leaving, I have a different vision. I was really, it was really something looking back at it.
Suzanne: It sounds like this history of refusing all kinds of things. I reject this university structure, I'll do better on my own. I reject this start up environment.
Andrew: Well, I mean not to get into psychology too much but yeah, I think I have a strong problem with authority figures and really listening to anybody, especially when I don't agree with them. We were creating a competitor to Salesforce. It was called Sales Metrics. We were building that we brought in a CEO. So I was kind of the lead in that whole effort and then we brought in a proper CEO. His name was Leo Nat and he worked at some other software company, a more traditional software company. It was sold for millions of dollars, so he was brought in to kind of move that product forward, get investors on board and really start the company.
We had the essentially the MVP. We had early adopters, we had several companies sign up. It was going well and Leo was brought in and basically at that point, the owner of the company didn't like that direction. He wanted us to build things for his call center basically. He owned this huge chain of call centers in Canada, pretty much the leader in call centers and when we put all this together and started investor meetings about getting funding, he didn't like the structure we created in that and how we would integrate investors, how we would kind of evolve the company and basically terminated the project.
That's, at this point, is when I was like you know what? I don't agree, I'm leaving. I could've sat there and taken that huge salary, really looking back after many years of struggling and being an entrepreneur. Maybe I could've made some different choices and just saving some money for a while and then trying to do something. But you know I was a bit hotheaded and so, that was that.
Suzanne: That was the last time you were an employee?
Andrew: I think it's at that point we met.
Andrew: 2006. Where I was again working on another start up. I have a whole series of startups behind me. We were raising money and you were in capital markets and that's how we met. I think then we joined to kind of work on this marketing company and quickly realized that it's, our technical proficiency was more evident to clients and could be better taken advantage of to actually create a more sustainable growing business.
Suzanne: Yeah, it's funny listening to you and looking back on the events because we're talking about sort of early, mid 2000s. Technology at that time, in my recollection was flash presentations. That was the big thing.
Andrew: Yeah. The flash.
Suzanne: All the companies, all the investor relations companies wanted flash presentations and basic HTML, you know? Three, four page websites and the landscape has changed so drastically, both in terms of what is possible now with the web and just the way that companies are thinking about product.
Suzanne: So you're mostly, except for that brief period in computer sciences as you describe, mostly self-taught. What's interesting to me is we're very much in this era of online learning, online education, organizations like General Assembly offering programs, bringing people in, learn to be a web developer in 12 weeks and it starts to raise this question I think for a lot of people. Well, a couple different questions. One, can you really learn to be a proficient web developer in a 12-week format or a three month format? And I think two, where do you as an aspiring developer, put your energy? What's the right programming language to learn? That feels like it's a bit of a moving target, I would imagine.
Andrew: First to speak to kind of, are these courses viable options for learning? I really think they are. Over time I noticed, early on, in a way I was frustrated by other people's inability to learn the way I do. I learn by, it could be any source. I listen, I read and I practice a lot. But some people require structure and by structure they need an actual instructor, they need to be guided specifically through certain steps. They're not self-learners and so I think part of this huge thing about online courses is, it depends kind of how you approach learning and what works for you. For the people who are self-learners, I think it's an awesome you know, landscape or environment because there's so much material available. You can literally learn anything you want and there's excellent courses.
I coded all the time. You know, Malcolm Gladwell, his thing, you have to do 10,000 hours to be great at something. I definitely agree with that. You have to be practicing and playing with it all the time, for whatever reason. It could be you know, you can see a lot of people online do things like they're own little projects to be like I want to create a doorbell or a video that's connected to an API that's connected to a webpage. Whatever you invent is good, just play with the medium and kind of implementing logic and connecting services and that kind of thing.
Suzanne: Yeah, it comes up a lot equally in the product management stream. Especially because, as I often say, product management is way less about specific things you can learn and way more about learning to think differently about specific situations, so it's conceptual. And concepts need to be assimilated over time and through application. So that's that challenge of, I've learned all this stuff, I'm amped up and ready to apply it and then needing to find a job to apply it in, a project to apply it in.
Andrew: Yeah, you have to like, that's why I say a good math or sciences background, you kind of, you have to have interest in it. You have to interest in how things work, why, how do you break something apart? How does it work on the inside? Assimilation's a good word. There’s one thing to read or kind of consume some content that explains a concept but you can only truly assimilate something by doing it. So you have to do it. You have to try different things and you know, the really awesome thing in technology is you can fail or make errors and it doesn't matter, you just write more code. The feedback loop is so fast and so you know, fluid, you could really feel almost what's happening when you work with code. In that way it kind of feels tactile.
I was talking about my grandfather and his workshop and I remember being a kid there and that feeling of tactility when you're making something out of wood, for me, anyway, programming is in some way the same way. It feels like you have a direct connection about what's happening and when you code and when you kind of experiment with stuff, you can get results, you can see what's happening. It feels like you're connected with what you're doing.
Suzanne: This is a big theme of our show is the unusual path that folks take to find themselves into product. Your path wasn't so unusual from the vantage of a young kid who discovers electronics and digital things and sort of falls in love with the tinkering and the building, but it is unusual for a developer in that you also really embraced the entrepreneurial path which is a different sort of creativity and a different sort of challenge. Typically a more, or has more extroverted requirement and you have been here in development and you were in design. You talked about design and print, you've been entrepreneurial and so all of those are kind of the flavors that make up the product manager journey. And now mostly your work is in that like, I described, that pressure cooker center of business, technology, and design. But you're a technical guy.
Suzanne: Chief Technology Officer and so, weigh in for us on this question that I certainly get asked a lot, which is how technical does a project manager need to be?
Andrew: Obviously, or maybe not obviously, but I listen to the show, and I've heard a lot of perspectives. That's why the show is really good. You kind of see how different people apply themselves in different companies. I use to think honestly that you needed to be technical. I really didn't see a world where a product manager didn't have a good understanding of technology. For me, if you're building software products, the technology aspect is like knowing your medium. For me it seems absurd. You have to know, the materials, how it works, how it's put together, what our kind of key points, key problems that could happen with assembly.
But, having said that, I am leaning towards, it's not necessarily as deep as I thought it needs to be because there are other quite important aspects. You know, especially around knowing the customer, getting out of the building, getting a feel for the market. Those are so important in terms of building the right product. So, the technical aspect is knowing how to build the product but that doesn't mean you know how to build the right product and there's a big difference there, especially having gone through so many startups, many of them that failed, what I've realized is the importance of those aspects. The importance of the research and understanding and not making assumptions and not building too much too soon without really knowing where the market's at and what it's ready for. These concepts existed before. There were brand people before, there were business analysts before, all this stuff existed. I think what's different is the construct is more refined. It's more holistic in terms of that singular, overseeing perspective about what does it mean to have a product. I still feel you need some technical knowledge and ability, but you don't need to have been a developer, per se. It’s also important to have the front-facing…the marketing, sales, the research aspects in you as well.
Suzanne: This is a common pressure I think for PMs is wanting to be a knowledge expert and learning to be comfortable with the fact that you're part of a cross functional team and the folks representing those functions are there to be the resident experts of those domains. So your job as a PM is less about know their job and more about knowing just enough about what that is so that you can translate it across other team members and sort of pull it all together for the vision is I think as you were talking about.
Andrew: Yeah. Exactly. It's knowing the important aspects of each of those domains of knowledge. So basically you can't know that without knowing the domains. So for me, you can't get away with not knowing anything in technology or the business aspect or the marketing or every aspect of a business because how do you know which parts are the important parts? How do you know which parts are important when you talk to developers? How do you know which parts are important when you talk to the executives, the business stakeholders? How do you know which prices are important to customers and where could it go wrong, where could it go right, what do you need to focus on? So you can't get away with not knowing all of them to the degree where you can kind of extract what are the important parts that I need to understand and I need to be able to kind of speak to that people in that domain so they understand me.
Suzanne: So would you be willing to, since you're here, help PMs listening everywhere understand a little bit more about the technical domain?
Suzanne: The place that I want to start is this tech stack, right. You hear this term kind of thrown around a lot and if you're not, as you say, if you don't really understand how digital products are put together maybe it's just a term that you're not familiar with. So let's start there. What is the “tech stack” and what is inside of it?
Andrew: Yeah. I mean I think that even that term has kind of conflated, evolved a little bit over time. I think originally it kind of meant the software components that make up your platform or solution. So it traditionally referred to what's at the database layer, what's at the business logic layer, what's at the interface layer? So I guess to step back a bit, that's the traditional way of breaking apart or thinking about an application is thinking about it in these three layers and that's kind of the three layers of any software application, conceptually. The interface part, which is really what the users are interacting with. The business logic layer, which is really what takes user input or information or system information from those and translates it in some way so kind of the thing that has the logic of what's happening to the data and then the database which the storage layer. Which is basically storing that data permanently, so the permanent storage layer.
Suzanne: Yeah, the term that I'm hearing coming out is now the product stack.
Andrew: Yeah. The product stack. It's better.
Suzanne: So many stacks, it's hard to keep track of them all.
Suzanne: So to go back to the tech stack at least the traditional definition as you've outlined it. Has that changed or you said APIs have changed that. Take us, give us the very quick version of APIs. I think that's another, product management is so littered with acronyms.
Suzanne: It's a scary place to navigate.
Andrew: I hate acronyms too.
Suzanne: So what are APIs and how do they fit into this traditional layer of software components as you described?
Suzanne: K. So far sounds good.
Andrew: Yeah. So I start building it and in the world before APIs, the information for what's the weather like in a particular place or where are flights coming and going from and how much they cost, it would be very difficult to get that information. You would have to integrate kind of these systems and they were very complicated ways to integrate or you could somehow get your own data that you put into your data center. It's tremendously costly and complicated and you would have like 100 people working on this trying to figure it out. You know, contacting the airlines and the Weather Bureau or whoever has this data and figuring out how is their data stored and how are we gonna get there and we have to install stuff in your side and install stuff onto my side.
So it's incredibly complex and with what's changed with APIs is now, the weather people or the company that has the weather data, exposes that information through an API, through adjacent API. And the flight company exposes their information through also adjacent API. So now when I'm creating this travel application, I don't need to go, I don't need to talk to them. I have a way to retrieve that data quickly, excessively and integrate it into my application. So I create that application and I put in a city and I query, I ask the weather API, hey, what's the weather in that location? It responds back easily and with the data that I need. I query the flight company and they respond back with the information. Boom, I integrate it into my application. That all could happen over a few days I could integrate that data and put it into my application.
Suzanne: If I understand correctly as you're describing it, essentially different products are loaning aspects of their data or their business logic to other products.
Suzanne: There's this theme of transparency that says here's how we do it, here's how you can borrow it and a developer working on it, to use your example, this weather app, this start up travel app, can now just by reading the instructions basically, have a quick entry point into borrowing data from other sources.
Andrew: Yeah, and how this affects the text stack is the decoupling of the interface layer and the business logic layer. So typically you had a tighter coupling of those two layers. Meaning the data processing and manipulation of the business logic layer was very close to an integrating to the interface layer.
Suzanne: Because all of the data and logic was your own?
Andrew: Correct. And so then you had this kind of advancement. It was called SOAP, another acronym. I forget what that one meant, but that was the evolution of like, we need to have better separation between these two layers so that we have one business logic layer that many people can pull data from. And finally the JSON API, the REST API came out, which really kind of unified a way of exposing that business logic layer. So that's why it's an exciting time in this type of development because you know, you can kind of almost pick and pull from different business logic layers throughout the I nternet. Like in this example, weather and flight information, but you could have any type of data that you could think of, there's probably an API for it. There's huge API repositories online that catalog thousands of APIs that exist and what they do and so it's so much easier to get and integrate data into some application and what is now evolving is that companies are now starting to create, expose APIs willing.
So there's kind of this protectionism around the business model, that's my business logic, that's my data, and that's my IP, that's the companies IP, I'm not going to expose it, but now there's ways they've realized they can monetize that for the number of requests you make from the API and so on. Especially the newer companies, the tech startups, kind of have that mentality already as they kind of are built. So for example, Uber has an API. I could interact with Uber and create my own interface on top of it and underneath it is the service and the data that I'm accessing but it's using my interface and my application and I'm just interacting with their API.
Suzanne: Right and I think Facebook, I credit Facebook in large part for spreading this mentality. Remembering back to some of the earliest web applications that we built at the development factory. Everybody wanted login with Facebook, commenting with Facebook, and those are all examples, I think, of that API integration. Where Facebook said, "Hey, we already have people using Facebook, if you want to let them log in with their Facebook accounts, we're happy for that." It made business sense for them because it was just more exposure. The most people that were logging in with Facebook the more they were able to attain users, attract users, so there was a business advantage.
Suzanne: To openness that, to your point, was a very different mindset of that closed, proprietary, “that's my IP, I don't want anyone to see it” and it's like, have my IP, because the more people that have it, the more I have access to those customers.
Andrew: Yeah, it's an essence the enlarging of platforms. I mean again, the idea of that existed, but I agree Facebook was one of the first to create kind of, it's almost a global platform. The examples you give aren't necessarily this idea of the adjacent rest API for Facebook, but they are examples of integrating what they're platform for accessing data or making user interaction easier. Absolutely it's a great thing for Facebook because it's a platform play and what that means is they become underneath everything, so if they own your login, you can't login to that other site, you go to some site, like mynotepad.com or something and you login using Facebook. What that really means is you can't log in to mynotebook without Facebook. So they become the platform for authentication which comes with a lot of control a lot of power and you know, subversively you might say they also do things like embed pixels into some of these processes to fully track you, so you'd be surprised how much data Facebook tracks, even with these methods other than their ad platform.
So absolutely, the ideas of platforms, the idea of owning the community and the platform around it is very powerful because when you're integrated into so many places it's so much harder to come in and defeat you. If you have, for example, the weather API that everyone uses, a new weather start up, has difficulty, it's a full ecosystem that relies on your API.
Suzanne: Right. It becomes an unfair advantage. A true unfair advantage.
Suzanne: So you're talking a lot about the benefit of accessing other system APIs in order to accelerate development quickly, prototype or release products where you didn't have to sort of pay to create a specific database for, like you said for weather, for flights, etc. You wrote an article on medium, I'll share it in the show notes, because I think it's a great article. It was called "API First," and it's talking a lot about the importance, not just leveraging other people's APIs, but actually building your own as a product company. Can you talk to us a little bit about why you think it's important that product companies have an API of their own?
Andrew: Yeah, it's a good point and an important thought especially for you know, startups to think about I think these days, because you can see that there's a market and there's a world where APIs are pretty dominant and do give you a distinct advantage for your company, for an ecosystem of data essentially. There's kind of this movement, I would say, or understanding of the idea of digitizing company or becoming a digital company and you might have heard things like UPS is a digital company now. Nike is a digital company. What does that really mean? It means that they're physical product or service is secondary to the ability for them to expose they're business logic and they're service is using things like APIs. This is prevalent inside the company. It's not just that they expose it outside, they have APIs inside the company which they expose to different parts of the company, so inside the company have this ability to innovate and integrate different parts of the business into new ways of applying itself.
So when you think about UPS, for example, being a digital company, inside you have this kind of innovation and they've exposed they're API, so now when you want to ship something or you want to get shipping into your website, you integrate with their API and that's how they've again created a platform that people integrate with and they get more embedded into the market, more embedded into all these other sites and services and they kind of sprawl and they have a community of developers around them. You have this large ecosystem and they're a digital first company because in fact that ecosystem is larger than their physical ecosystem and it touches more people, is more integrated and more valuable than necessarily the physical aspect of the business.
Suzanne: Right. I mean you spoke before about monetizing through APIs and I think SalesForce is probably the most well known example of this.
Suzanne: It's oh you, number one you have to upgrade to professional or enterprise level accounts so that you can even access the API and then we're still going to charge you per call. So I think one answer it sounds like is, it could become a revenue source for you, potentially at scale but maybe even as a niche service offering. I'm glad that you brought up Nike because I think it shines a light on another element which you're getting at, which is APIs as a way of improving or integrating a customer experience. I remember, you know, working for years with agencies there was this sort of hey day of everybody wants a microsite. Everybody wants an app. So you might have a big brand like Mcdonalds and they've got six or seven different agencies that are all working with them in one capacity or another and every agency at the time is vying for an opportunity to build some useless mobile app that no one ever wants anyway.
So there's the McDonald's contest app over here and the McDonald's CoCa-Cola combined app over here and what became evident and frustrating for users is, I have all these different apps and it doesn't seem like they're talking to each other. And they weren't talking to each other.
Andrew: Yeah, that's a really great use case and demonstration of the potential power of an API. So suppose in that scenario McDonald's said, You know what, we're going to come up with an API for centralizing user data and this API allows any agency to interact with that API and continue the profile and experience of the user in meaningful way. Suddenly instead of all these separate experiences, separate registrations, you have a unified way of creating the profile and continuing that profile in the entire, you know, universe of different promotions or campaigns or so on, and apart from this McDonald's retains all the information and all the power of that information, of that data, versus the agency retaining it, using it for their own purpose and not using it properly.
Suzanne: Or even just the fragmentation of it all.
Andrew: Right. And it's fragmented so, you know that's a great example of you know, when you think about becoming a digital company, being more digital as a company, there's very good use cases for impacting the customer experience and at the same time creating huge business value and that's one of the very powerful aspects of APIs is exactly that is impacting those two areas and making it even easier for a development to happen for developers. And in that world, let's say McDonald's did do that thing that API, you could say to the development community, make your own campaigns, come up with creative ways to promote McDonald’s. Here's our API for accessing the user information. You know, you have to control that a certain way but that's really what empowers developers to play with it and be innovative.
That's what creates this kind of atmosphere of as a developer I'm part of the community, I'm part of building something I'm part of experimenting with what we can do with this information and you have this crossing of using data and creating interfaces and customer experiences that you didn't have before and you're not, your internal team at McDonald's could have never thought of all these things that thousands of other people have thought about or played with and something really innovative could emerge from that.
Suzanne: Right. And to close the loop on Nike I think it's just maybe because I have brand affinity there, but I think they have so many products and I'm a user of many of them. Nike Run Club, Nike Training, Nike.com and I love as a customer that my log in and my profile follows me through those places. I know that it's to their benefit that they're collecting data and they're able to serve me up ideas and offers that are specific to me. It's okay, because I buy in. I choose to participate in their ecosystem and therefore I value the fact that their ecosystem knows me. It's not that you talked about silos earlier on in our conversation and that also reminds me of the classic, dealing with companies like American Express and you get two calls on the same day from the same company and neither seems to have any idea that you have an active account with them.
Suzanne: They're trying to sell you a new product. I mean it's poor.
Andrew: Yeah, and certainly some of those point to kind of the I guess the dysfunction of the company as a whole of not thinking through that customer experience and that kind of ties back to the product mentality and treating that as a holistic idea and some of it also has to do with this infrastructure aspect or technical aspect of APIs of thinking how to be more holistic and more centralized in a way and exposing that, allowing interaction with that by other parties, by other departments, within AmEx by people outside of AmEx, how do we create that community? How do we allow the community to build on top of that to create even more value? So in the Nike example, I don't actually know, but maybe there's a way for developers to access your runner profile and your last runs. So let's say I'm making a meal planner or something.
Suzanne: You mean candidly that data is taken a little bit of a downward slope, so hopefully not right now.
Andrew: Let's not access it right now. But let's say I built a meal plan application and I integrated with the Nike API and so in my app, I can pull in how much you ran today or this week or where you've been and I could do things like recommend the appropriate meal. I could do things like recommend a meal at the end of your run path, typical end of your run path based on information I have about restaurants that would be suitable. So that's an example of like, you could suddenly be creative about it, pull in that data, add even more value to it and you have these kind of increasing value chains when you integrate these services and API's together.
Suzanne: Okay, moving away from APIs for a moment, and coming back to this concept of how technical does a PM need to be understanding how products are put together, I think another topic of importance is, maybe perhaps even the most important for PMs, especially if they're not technical and not really required to own that knowledge, that domain expertise, is assessing the impact of change. So change is inevitable in product and if your organization is agile and embraces this sort of adaptive qualities of the agile principles, then you know change is inevitable because you're pushing out a feature, you're collecting feedback from the users, you're collecting feedback from the stakeholders, you're iterating on that feature...
Suzanne: …on that module. So can you talk to us a little bit about the impact of change or the cost of change in the development world and what we as PMs can take away from that in order to be better at our jobs?
Andrew: Great question. I think it does come up a lot in terms of, especially if you're less technical, in this ability to understand what a requests means or how to think about the impact of a proposed change. I think this is where it becomes necessary to at least have a fundamental understanding of how these applications work and these different layers of tiers to an application and sometimes I like to think of it or express it as a metaphor, but it's like a building in that the data layer, the permanent storage layer, is kind of like the foundation, the business logic is the structure of the building itself, the beams and kind of the making the rooms, and inside the room the interior decoration and that kind of thing is like the interface.
So that's helpful in terms of realizing that when you impact or when you need to change the data layer, the storage layer, it might impact every single layer above it. It might not, but that's rare. Maybe you change the foundation just away from the building or something and you don't need to deal with the building but sometimes, if you need to change the foundation and it happens to be below the main beam of the building, you realize it's a really big change. You have to deal with structurally reinforcing that beam while you do the work and it might impact all the units in the building that are next to that beam. It might impact the whole structure integrity of the building itself and so you know the impact could be huge.
I think one of the aspects of thinking about impact and thinking about where this could potentially lead is being able to, at least at a high level, be able to discern, will this impact just the interface, will it impact the business logic layer, or will it go as deep as the data layer and then being able to talk through that with your team, with developers and understanding that there's difference when those areas are impacted is very valuable. I think that the development team themselves will really appreciate the knowledge you're bringing to the table in understanding that it's not just copy and paste, fix something, even if it's a seemingly interface change. I just want to change the number that I show in this interface. It could mean now I need a new calculation, which means business logic impact and it could also mean now I need to store data in a different way which could mean data layer impact. So this seemingly small adjustment to what I'm showing the user has kind of a ripple effect through all the layers of application could be a big impact.
Suzanne: So the cost of change increases the deeper into the building construct, the deeper into the application construct that you go?
Andrew: Exactly. I think it's a, I want to be mindful, some of the more technical listening, it's a rule of thumb. It doesn't necessarily always apply but in general when you're going deeper you're having a much larger impact because it could mean affecting all the layers above it. When you change the use of a font in an application, there's no way it could impact the data layer, but if you change the data structure of a database there's many reasons it could impact business logic and also the interface layer. So it's just knowing how deep in having that conversation with developers and knowing that that's where it's going to go. Where is it really going to change the application, which layer and how does that impact the other layers?
Suzanne: Let’s go back to something that you talked about earlier. I asked you about earlier which is you know, as a developer, which programming languages are good to start and focus on. You see a lot people advertising for full stack developers. Everyone wants a full stack developer and even just in the conversation, one thing that's emerging for me is each of those layers of the tech stack as you've described them, represent a very different type of knowledge. A different type of thinking.
Suzanne: A different type of understanding. So how valid in your opinion is this term, full stack developer? Is it possible to be a full stack developer truly?
Andrew: Good question and I definitely see that come up often, right, and it's kind of a term being thrown about a lot and it depends a bit on the context and if you're building WordPress sites you can be a full stack developer. You're not exactly inventing something novel or doing something really challenging. I think the difference with products is you do need specialization in understanding each of these layers as you've said, you need to know what the impact is of structuring data a certain way and how, let's say you're making a reporting application or an application that has a reporting component. The way you structure the database and how you index the data and how the relationships are between tables or which database do you use. Do you use Mongo, do you use My Sequel, Maria, do you use Microsoft, Oracle, whatever? All these could have impacts in terms of performance and yeah, I don't really see a singular person having the ability, especially when it's a complex application or a high performance application being a full stack developer.
So it's valid, you know, to a degree, but if you're building a quick prototype, you're building something simple. You're building a website. You can get away with it, especially these days, there's frameworks for quickly scaffolding databases. I wanted to say these people, it sounds a bit derogatory, but full stack developers of that nature, you know can get away with, I know the idea of tables, of data relationships, of queries, and that's good enough for sure to make a simple website a prototype. You don't need to be a data scientist, but if you're then building Uber, and there's millions of requests on your database and there's reports you need to compile and there's transactions you need to take care of, no, I don't think there's a full stack developer that could, you know, equally code the interface and the business logic and look at the data layer and be proficient in all of those layers. You might have understanding in those layers, but you do need specialists for dealing with each of these layers.
Suzanne: Right. It brings back the generalist versus specialist construct that even, I think, is prevalent for PMs. Is that to be a product manager who is absolutely versed and excellent as a user experience expert and designer and clear about usability and conducting usability tests, learning from them as well as understanding programming and all of the layers as well as understanding the populated landscape of digital marketing strategies quickly shines a light on the difference between, I know a bit about everything, enough to be conversational or enough to participate in the strategic discussion, which is different from I can really own this and be excellent at this one thing.
Andrew: I have a high regard for good generalists and I think I am one myself. So I do want to define that as, you know, you can't be a generalist that doesn't have significant knowledge of each body or each domain. So when I say generalist, I don't mean like you read a book and you know, learned about it for a month. That's not a generalist of that topic to me, that's just you kind of know something, maybe. So when I say generalist, you do have to have a fairly good depth of knowledge in each of these fields. I think it is very challenging to have enough knowledge in each of these fields to be a proficient or good project manager. I think you have to be interested in learning a lot. You have to assimilate a lot of stuff to be a really good product manager. 'Cause all of these domain have specifics and you have to know enough to again understand what that domain is abut and speak the language of the domain. So when you go talk to a database guy you know what a query is.
Suzanne: Or gal.
Andrew: Or gal.
Suzanne: Just want to throw that out there, or gal.
Andrew: You know what a query is and when they're explaining the length of the query, you know, you get the concept, you get what they're talking about. It might take you a second to get them to explain it an a clearer way, a cleaner way or something like that, but it's not like you're lost. He says query and you're like, "What's a query?" That would be not good.
Suzanne: Isn't what's a query a query unto itself?
Suzanne: On the same topic of speaking the language, right, another thing that is essential for being a great product manager is your ability to persuade or get different team members aligned and that those different team members perceive the world and interact in the world very differently is a big challenge for product managers.
Andrew: For sure.
Suzanne: I think many people have specifically experienced the challenge of working effectively with developers.
Suzanne: So as a developer, I mean you're a jovial guy, seem pretty easy to talk to, what advice can you offer to PMs for better relationships with their development team?
Andrew: I have that question posed to be me quite a bit as well, because I'm in this position of CTO or whatever and I'm supposed to know better I guess. Maybe I do, maybe I don't, but what I've found typically the problem is that you are not empathetic and you're not speaking their language, so you often, I think from the perspective of the developer, the impression is you just don't get it. You just don't get it, you talking about silly things, silly like you're using an analogy or metaphor and you're trying to explain to me, the guy who makes the code how I should do this thing when it's more complicated than what you think.
So I think one, having more knowledge in the domain is very helpful so that you can speak that language. You can understand where they're coming from when they say something is complicated or it takes more time and second be empathetic in the situation of coming at a problem or coming with a problem and knowing that they think about it a different way and not being too I know better about it, essentially, and being open to understanding their perspective and seeing how they think about where to solve the problem.
I think another thing often with developers is they have a tendency to say no right away. They want to shut down ideas right away in that, you know it is complicated. It is complicated to do some things but there's always a good solution. There's always a solution that usually every developer is a problem solver and they can rethink the problem later and kind of come up with a better solution later. So sometimes it's better to just leave it, even with a note and good developers never leave a problem alone. So you can trust....
Suzanne: Sometimes to their own detriment.
Andrew: Right. So you can, I think it's a very good way to state a problem, and they're like no, it would take way too long. It's impossible. I would have to change the database and like so on, and then you'll be like okay, just maybe think about it. I don't know. And then come back the next day and I think you'll see that they've did not let it go and they've come up with alternatives in terms of solving the problem and suddenly are more open to how to go about it. I think that's an important thing to know that there's a natural tendency for an engineer or developer to be like, "You don't get it. It's more complicated. It's not possible in this context" of you're saying in next sprint or next release or whatever, and sometimes you just leave it and let it sit for a bit so that they can think about alternatives or discuss it with themselves and not be too like, I know it's possible or you need to do it this way or it needs to be done. I think valuing the thought process and the problem solving process is a good way to be empathetic to a developer.
Suzanne: Yeah, I think those are all really good points. I like had this visual come up for me of having a feather and just sort of tickling it against that problem solving nerve.
Suzanne: Nerve system where it's like now you've got me all thinking about how to solve a problem and it's a good way to ignite the passion in folks.
Suzanne: I think another one that I would throw in the ring as well is sharing the vision, sharing the strategy.
Andrew: For sure.
Suzanne: Not treating developers, whether consciously or unconsciously, as code monkeys is the term that comes up a lot, but actually recognizing that they are creative people as well in their way of being creative and that not only can the organization benefit tremendously from sometimes having them in the room or in the conversation, but that it actually, I think, helps with buy in.
Andrew: Absolutely. That's a really good point and I think that's a very common, you think about, I think about this world of finally in the product strategy room, you've brought in the designer. This is a common kind of written about concept of bringing the designer to the fore in terms of your product thinking. It just points to the fact that you still ignore developers. So there is this strong, strong impression for developers and for everyone that it is code monkeys. They just do the work. They're just manual labor in essence and that's a really poor way to think about it in my opinion. I think the development, programming is a very creative medium and you're problem solving constantly at every level and I think that level of thinking is very valuable and should be as brought to the front as much as possible and I think you'll see probably over the next few years that the start ups have usually the founder or part of the founding team a technical person, but it's still not prevalent in terms of a company, to bring that thinking to the strategic level.
So I do think it will evolve over time to be like, yeah, we brought the designer, but we forgot the developers. We should bring the developer to the table as well in terms of having that input at a strategic level, but taking it back to kind of development team, I do think often they're kind of put in the back room in the dungeon and absolutely sharing with them the vision, the why, where it's going, what is really the idea behind creating something or solving a certain problem really helps them to feel part of the team and kind of give more to the project.
Suzanne: Thank you. We do, I like to ask all of our guests as we move toward the end of the interview here, advice for up and comers, words of wisdom or cautionary tales for places or failure and just celebrating in the role. I want to just frame it a little bit more specifically for you, to take advantage of your domain expertise. So a lot of times people end up in product because they are currently working in one of those domains that product touches as a cross functional role, so you're a UX designer and you want to become more strategic, more holistic, around the product development process. You're a developer and you want to become more strategic, more holistic around the product development process. What advice would you give to folks listening in that are currently working in developer roles but who feel that they're ready to move into that more strategic center of product management for making that transition?
Andrew: Yeah, I think you know, I haven't often, maybe that's kind of a symptom of this code monkey kind of mentality. I haven't often seen really developers move into product management kind of roles. But I think it's a very available path if you will and like I was saying, you know, it's an important perspective in the product world, having that technical expertise. But I would say if you want to make the transition and you're more towards development, you have to have a very keen interest in the business side of things and in the customer side of things in the UX. So I think you need to move more towards understanding drivers and these worlds, how people think in these worlds and how to apply yourself in these worlds, so that would mean being a lot more proactive in you know, let's say you're doing experiments and building your own software and whatever, thinking a lot more about the UX side of it.
What is the interface? How does the interface impact the experience of the user and then going through and thinking like, how can I make this into a business? How could I position in it in the market? How could I sell this product? Once you start going through that you realize how much more there is. I think one of the flip side of it, we talked about the developer and being empathetic as a product manager, the flip side is the developer to be empathetic to these concepts and I think often a mentality from an engineer's point of view is I do the hard part. I do the hard part of figuring out how something works. That's really hard and I did that. The interface is like whatever, it's easy. The business is easy. But that's delusional, I feel. It's strongly delusional because when you actually get into these domains, it's incredibly difficult as well.
You know, having a good interface is not simply using a bootstrap template and making the buttons pretty and having a good business and marketing and sales is not simply putting up a landing page with three packages. You're overly simplifying and it's ironic that they, you know, they're upset when they themselves are simplified, but then simplify these other domains. But if you're a developer you want to move towards that. That's where you need to go is expand your mind and look at these areas and have more curiosity, more engagement with interface, how things work on an interaction level and how business works. What are the drivers to business, what are the drivers to acquisition, to retention, those kinds of things.
Suzanne: Yeah, I think in the history of product businesses that have started up and failed, almost none of them failed because they couldn't build the product.
Suzanne: So I think it definitely does honor what you're describing which is growth is hard.
Suzanne: It's in fact the hardest part I think in many ways for sure. What about hard lessons? I mean what in particular do you think is challenging about the product manager role that they sort of don't tell you about in the books? You kind of unpleasantly discover it on the job.
Andrew: That's a good question. There's so many challenges frankly. Probably the toughest is pointing things in the same direction with all parties. I think since you're in the middle, you're getting pulled in all directions, and when you're really successful is you actually from you kind of push out a sense of direction and a sense of integrating all these ideas into that where am I going with it? You think about sales and marketing and wanting certain things from the product. You think about the customer feedback and wanting certain things from the product. You think about the dev team and what they want to be working on and how they're working and what's possible.
All these things are kind of around your head, in your head, outside your head, everyone's interacting and there's pressure to do things, but ultimately when you are able to assimilate all this and get everyone to agree that this is the right direction and this is the right list of priorities, the right plan or product plan or roadmap, I think that's the really hard part and that's what really makes the successful ones successful is they're able to assimilate all this information, come up with the direction, and then again go outside and convince everyone that this is the right thing to do and that's you know, incredibly difficult I would say.
Suzanne: May you said it before in talking about how you came to be in technology, but what is your favorite thing about product management, being a product manager?
Andrew: I guess it would be the necessity to learn. I think it forces you to think about so many things and look, I'm curious, I like to learn, I'm curious and so it's great for that. You know, you need to know all these things. It's almost like finally a place for a good generalist, you know what I mean? I think in many ways generalists have been frowned upon for a long time in society and I think a product manager is a de facto generalist. You have to be that person that understands a lot of things that integrates all this information and so having found the place for my generalist-ism, I think that's the greatest thing is you know people need you to know a lot of things and integrate that information and that comes with the requirement of being curious, learning a lot, communicating a lot with others, and that's, for me, fun and exciting.
Suzanne: I guess for you specifically, learning a lot as long as nobody tells you how to learn.
Suzanne: What, on the topic of learning, do you have any, you said you listen to the show. We love fans of the show. What other recommended resources would you like to contribute? For those of you listening at the 100productmanagers.com website we've got a resources page. We include all of the recommendations from our guests there. Andrew, do you want to add any essential titles to that growing list for our audience?
Andrew: Well I've happened to have seen the site and there's a lot of good stuff on there so it's really difficult, I guess, to contribute something unique. I think a lot of the guests have pointed to a lot of product management resources so.... I think one of the guests pointed to the fact that you should learn about other things other than product management and that's what I tend to like to do is you can't get too deep into these concepts and philosophies of product management in terms of, you know, there's only so much you can try at once. There's only so much you can actually act on. So sometimes I have this sense of people like you read every methodology but it can't all be useful. I think you have to be more methodical, you know, thought through about what you're applying and what you're learning.
The other side of it is, keeping your mind open to everything else. It's almost like you have to be this, learn about everything. I mean everything. So one of my favorite places is Quora where you have random questions and you know they send you a newsletter every day with the top questions. It's random information and you know, I like that. I like that break from product, technology, you need this kind of sense of all this random stuff and what people are thinking about and Quora’s a great one, you know, Medium is certainly a great one where I don't actually read about technology on Medium, it's more social issues, what's happening the world.
One I would mention, I want to mention that's really great, especially if you're a nerd is PBS Spacetime which is fantastic. It's on YouTube. It's this like British guy talking about astrophysics and physics is another one of my, I really love physics. It's a really great show, so I would strong recommend, if you like physics, if you like you know, astronomy, if you like you know, the meaning of relativity, kind of concepts, it's a fantastic show. It's very accessible. I mean it is a bit more than kind of entertainment science show, but he's got a great way of breaking it down. So that would be my contribution I guess, because there's so much on product already.
Suzanne: PBS Spacetime on YouTube?
Andrew: PBS Spacetime. Yeah.
Suzanne: Cool. Do you have a side of the mug inspirational quote or mantra that you use to govern yourself in the world that you want to share with us before we go?
Andrew: I've had a few, I guess. I like these kind of catch phrases in a way. It reminds you kind of. The one at the moment that comes to mind is, "It's not a problem, unless it's a problem." Why kind of I've come up with that or say that is you know, a lot of people like to waste a lot of time when it's not really a problem. So I think it's just something lately that's come up where especially with clients and stuff and situations where we're talking about something and, "Is that really a problem? Or it's not a problem?" So let's not really spend time on it. It's not worth the energy, it's not really a problem. So I guess that's the one at the moment that I could think of because it's come up in the past year or two and it's been the mantra of the moment.
Suzanne: I like that a lot because I'm a big proponent of not worrying.
Suzanne: Because it doesn't typically lead to solving problems and is, as you say, generally outside of any context. I think it also really encapsulates the idea of lean practice, which is about reducing waste and not worrying about things until they're proven to be things that need to worry about so. "It's not a problem, unless it's a problem."
Andrew: Unless it's a problem. That's right.
Suzanne: I love it. Andrew Bodis, Chief Technology Officer at The Development Factory. Thank you so much for joining us on the show.
Andrew: Been a pleasure.