The Giff Constable Hypothesis: Efficient Teams Learn Before They Build

In this episode of the Product Science Podcast, we cover Paypal’s transition from Waterfall to Agile and how to manage high performing teams. We also cover how to be a product manager without an engineering degree, and how to use active listening to empower teams by asking the right questions.

The Giff Constable Hypothesis: Efficient Teams Learn Before They Build

Giff Constable is a product leader, entrepreneur, and author. He was the Chief Product Officer at Meetup.com and earlier was the CEO of Neo, a global innovation consulting company acquired by Pivotal. He has sold 3 businesses while at the helm and helped build many others. He is the author of two books on how to test new business ideas, which are used as core curriculum in top university entrepreneurship programs and accelerators around the world.

In this episode of the Product Science Podcast, we cover how good product managers learn from their mistakes, how to better test ideas, and how to be more vulnerable and honest as a manager.

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

Resources

Questions We Explore in This Episode

How did Giff get into product? How can product managers bridge different parts of a company together? How can you tell if your product is before its time? What happens if you’re buying your traction vs earning it? How did Giff get into book writing? How did Giff build the material for his books? How do you test if an idea is a good idea before building a product? Which of Giff’s books should you read to better understand product? How do you test human behaviors? How do you better understand a customer? What validation tools should every product manager have? What validation and testing tools are best and under which circumstances?

How do you know if you’re doing product poorly? Why is it hard to get companies out of an “always be shipping” mindset? How do you know if the product you’re building is the right product? How do you know if you’re getting the right responses in your user research? How do you refine your user research to filter out the the best data? How do you combat a company culture that does not value proper product ideals? How do you scale up user research? How do you learn to do product management right? How do you create more organic user interviews?

What do you do when you’ve made mistakes? What lessons do you take from your failures? How do you communicate when you need help? How do you analyze your research data? How different is product theory from the realities of working in product? What are the limitations of learning about product in the classroom? Why is A/B testing too late to start testing your product ideas? Why is A/B testing a poor way to know if you have a good idea? How do you create lightweight and efficient testing? How do you know what product ideas need to be tested? How do you create feedback looks between teams?

How much is being a product leader, helping teams communicate better? From top down, how does a clear strategy help promote autonomy for teams? How does a clear strategy help promote communication between teams? If teams are getting many little things wrong, does that mean they are failing or learning? How do you build a company culture where people are free to make mistakes? How can you use strategy and road-mapping phases as an educational moment for junior product managers?

What to do if you come off as an arrogant product manager? How can transparency into your methods and motives help with team morale? As a leader, can you be allowed to be vulnerable? How can your body language make you seem arrogant? How do you learn to give and receive critique? How do you make feedback, kind, honest, actionable, and specific?

How can being a product consultant help your education? What resources are available to expand your education in product by yourself? How do you know if a growing company is doomed to fail? How much can other communities (i.e. design, engineering, user researchers) help you better understand product? What are 3 things every consultant needs to do to be successful? How do you figure out the economics of your business of your consultant work? How do you know if your company’s internal incentives are set up properly? How do you set up incentives that allow employees to take risks and make mistakes? Why should product managers study business & finance?

Quotes from Giff Constable in this episode

Product looks easy from the outside, but all these techniques are hard in reality.
If it's an A/B test that means we've built the thing. How do we figure out if this is a good idea before we've built the thing?
You rarely get crystal clear answers in anything in product, but you should be getting insights from discovery that should be helping drive to better decisions. If it doesn't feel like that, you probably need to look at how you're approaching it.

Transcription

Holly: This week on the Product Science Podcast, I'm excited to share a conversation with Giff Constable. Giff is a product leader, entrepreneur, and author. He was the chief product officer at meetup.com and earlier was the CEO of Neo, a global innovation consulting company acquired by Pivotal. He has sold three businesses while at the helm and helped build many others. He is the author of two books on how to test new business ideas, which are used as core curriculum in top university entrepreneurship programs and accelerators around the world. Welcome, Giff.

Giff Constable: Hey, Holly. Good to be here.

Holly: I'm excited to talk with you today.

Giff Constable: Yeah, likewise.

Holly: Yeah. So you have a rich history. Let's kind of go back a little bit. How did you move into product?

Giff Constable: Oh, Lord. Yes. Well, when you talk to people of my age, which I'm about to be 50 to disclose that to the audience, most of us have rather colorful and unusual directions into product. My first job was at a software startup down in Texas, in Austin, Texas called Trilogy. And back then, there wasn't a product job. We didn't even have designers. There were business people and there were engineers. But I ended up kind of playing a product role. I was the bridge between the business and the product. A lot of the beginning of my career was either working at startups or starting my own companies. I was wearing a lot of business hats, but where I had the most fun was when I was working with engineers and designers to ship something, both the value to customers and value to the business. So about halfway through my career, I said, "Okay. Well, if I'm not starting a company, I need to pick a lane." Because you don't get to just do everything the way you do as a founder, and I said, "Product is where I want to go." So I made that sort of turn. I've been leading product teams now for, well, a number of years, I guess. I've been heavy into products over a decade now or more than that actually.

Holly: Yeah, I'm sure. So you have a lot of interesting steps along the way. You mentioned that you've sold three businesses while at the helm. What was the first one?

Giff Constable: The first one was back in the dot com days, again, to date myself. It was a marketplace for freelancers and consultants. Good friend of mine from Trilogy had been trying to act as a freelancer, was struggling to find work and we thought, "Okay, let's match make." The internet was a fairly new thing. We realized that was too high-end transaction for that time of the internet and we sort of pivoted to move downstream to advice and information and tried to create a marketplace for that. It was also still too early, as most of those ideas were. But the fun thing is watching over the years as so many of these ideas have come to fruition.

Holly: Yeah. How did you figure out that it was too early?

Giff Constable: You could see it. You could see it both with what we were experiencing and the feedback we were getting from customers and traction or lack thereof. And you could see that if you were paying attention to what was happening in the industry, there was a lot of money floating around as everyone knows. There's a lot of money floating around today and you were seeing a lot of traction being bought, but not necessarily being earned. I'll be honest. I struggled during this time period because as a very product-oriented person, I wanted my product to earn its success. The people who were willing to just buy it ended up doing much, much better than me, financially. At least if they got out in time. But you could see it everywhere that a lot of these ideas were exciting. They were interesting, but they were just a little too ahead of their time, both because of the infrastructure as well as just the sheer number of customers and the comfort level and the behaviors. It's really, as you know, as a product person, it's hard to change behavior. And that was a lot of that going on at that point in time.

Holly: Yeah. Well, I'm curious. So you've written two books. Well, two nonfiction books and a fiction book as well. Right?

Giff Constable: Yeah. I wrote a sci-fi book last year on artificial intelligence, which was a lot of fun.

Holly: Yeah. That sounds like a lot of fun. I'm really into sci-fi, so I definitely should put that book in my reading list.

Giff Constable: Oh, please do.

Holly: Yeah. It's Becoming Monday.

Giff Constable: Becoming Monday, that's right.

Holly: Yeah. Cool. But you wrote two nonfiction books and I'm curious to hear more about how you develop the skills that you teach in those books. So tell me a little bit about starting with the first one.

Giff Constable: Well, the way I've typically written, it's not me acting as journalist where I don't know about a topic and I go investigate it. Now, these have come about of me working on an area, trying to build expertise in an area, learn it from a lot of other people about that area and then writing as a way to both share what I've learned as well as learn it better. I really like to write to think. And it's similar to teaching. There's nothing like teaching to have to really learn a topic. It happened organically. Again, back then I was more in the startup world than in the product world, let's say. They overlap heavily, but I thought of myself more as an entrepreneur than as product leader. I was really obsessed partially because I worked on things that had done well and some things that had bombed. I was obsessed with this idea of how do you figure out whether an idea is a good idea? How do you get ahead of that problem rather than just having to learn through tears, and grit, and sweat. So that's what brought me to Steve Blank's book, Four Steps to the Epiphany, which was the precursor to the Lean movement that Eric Reis really kicked off. I was a really early adopter of Lean and I was trying to put those ideas into practice, doing some of it well, some of it badly. And I was really involved in the early community. I ran a meetup. I ran the New York Lean startup meetup for years. I got to know a lot of the people that we think of thought leaders now. Because back then all of us were just trying this stuff on and trying to figure out how to make sense of it. So I would get asked to teach it at different startup weekends and accelerators and things like that. Actually it was Frankel Milosky at NYU's entrepreneurship program who came to me and said, "We need something more on customer discovery. We've got your blog posts and your talks, and Steve Blank did a bunch of videos, but we need something more robust. Would you write it up?" So that led to the first book. And then actually it was through doing Neo. Eric Reis was loosely involved in Neo, but the other folks that you might recognize were David Bland, and Josh Seiden, and Jeff Gothelf, and some real thought leaders in the Lean space. We had all these cycles. It's one thing you could do as a consulting company that you can't do in operations inside a company. And to be honest, I prefer being inside a company as opposed to consulting. But as consulting, you get to run a lot of reps. You get to run a lot of cycles and we did a billion different kinds of experiments of testing ideas. And we got to see what kinds of experiments worked and how fast can you run them. Where does it work and all that stuff. And that's what led to the second book was basically trying to share all those lessons from all those at-bats that we had at Neo. And not surprisingly, David Bland also wrote a book because it was a super, super focused, intense lens on my experimentation.

Holly: Yeah. So the first book is talking to humans and the second book is testing with humans.

Giff Constable: That's right.

Holly: So tell us a little more about how would a listener know which book to read to help them?

Giff Constable: Well, honestly, this will sound funny, but you need to understand both topics. I don't care whether you do it through my books or something else. But one of the things that I've been trying to get across is that you need to use different tools to learn different things. So if you want to predict future behavior, the best thing to do is put people through some sort of experience and see what they actually do, measure what they actually do. That's an experiment, right? Don't talk about it. Go do something. Have them do something. Watch it, measure it, and see. Now, the good news is you don't have to build the full product to do that. So if you want to get really good insights into how someone approached a problem, why they tried to solve the problem, what their motivations were during it, then actually listening to them asking them questions, interviewing them going deep is a really good tool. You don't use the one tool for the other problem, right? You got to choose your tool wisely. And I say the same thing about surveys. You can use them for certain things. They're very poor for others. For me, I find that if you want really objective information, factual information at scale, surveys are a good tool. If you want to understand how people are approaching a problem and you can actually do it for your problem space, then try to observe them. Don't talk to them about it, try to watch them. That kind of ethnographic research is often tough to do for a lot of product teams. But if you can take advantage of it, absolutely take advantage of it. So it's like you want to have all these different research tools in your quiver, these learning, these validation tools. So there's the interviews, there's surveys, there's observation, there's experiments. These are a lot of the big ones, and you want to choose the right one for the right job, but you've also got to do them well. And every single one of those methods that I just mentioned, most people do pretty badly because all of those methods fight against our cognitive biases. And you think of that, this stuff is really simple. Just talking to people, listening to them, asking them questions? We all know how to do this. We know how to do this since we're two years old. But it's really difficult to do it well. Same thing with experiments. Most people's experiments are too vague, too big, too unstructured take too long, too expensive, too product like. It usually takes having to learn the hard way. The books are simply a way of trying to help people, shortcut having to learn everything the hard way.

Holly: Yeah. I love that you talk so openly about most people doing it poorly. I think it's really hard for people to realize that they're doing it poorly.

Giff Constable: Yes.

Holly: Do you have any insights into helping people identify that?

Giff Constable: Well, the question is, does any of this stuff feel actionable? And are you struggling to make time for it? Now, most businesses, honestly, especially if they are led by old guard managers struggle to find time for this stuff because the older mentality was speed. It's all about shipping things quickly, right? Get things out the door, quality and speed. That's what it's about. And as we all know, at this point in time, what that's completely missing is are you actually building the right thing, right? If you run really far away from your goal, you are further from your goal, not closer to your goal. That lesson is still sinking in at, I would say, most companies out there. But there's a growing group of people that appreciate discovery. And there's the latest edition to that is what Teresa Torres added with her book last year is Continuous Discovery, how important that is and that was a really wonderful addition to our field. But if you're struggling to be able to do it, that probably means that it doesn't feel useful. If you're struggling to get any actionable insights out of either of these things. It probably means you're not doing it that well because these are really powerful techniques. And you should be able to get insights. There's often noise that comes with it too. It's not like you get crystal clear answers. There's nothing in product. You rarely get crystal clear answers in anything in product, but you should be getting insights that should be helping drive to better decisions. If it doesn't feel like that, you probably need to look at how you're approaching it.

Holly: Yeah. So if you're having trouble getting actionable insights and you need to take a look at how you're approaching it, where do you begin?

Giff Constable: Right. Well, there's two things that I think folks who are struggling to do this need to do. One is to try to sneak it in. Now, you got to know for your particular culture, what you can get away with and what you can't. What I often talk to product teams and they're saying, "We're not allowed to do this." And to a certain extent, I think it's a job of product leaders to create that space, to allow their teams to do this. But as a product team itself, you've got to figure out how do I just sneak this in? So I'm not asking permission. This is just how we work. Do we ask permission to write user stories? That's just how we work. Do we ask permission to ask questions about how we're doing and can we move faster? No, it should just be built into how we work. So one, just try to do this stuff and start doing it in lightweight ways. Don't do it in really heavy ways. But the second is get out there and learn some of the basics. So whether it's my books or tons of blog posts that are out there or podcasts on this stuff, there's a lot to learn from. So don't try to reinvent the wheel and then just start doing it in small, lightweight ways. Be scrappy with it. And you will do it badly at the beginning and forgive yourself for doing it badly at the beginning. Everyone does this badly at the beginning. When I first started doing this, this was a startup called Aprizi that I'd done back in 2010. Really I was into Lean. I was trying to run an experiment and my first experiment probably took us three months to do because we were building product and I was still such a product-minded person that we were trying to build product and this building product comes with all this stuff that you're supposed to do to professionally to build product. I hadn't quite realized that I needed to liberate my brain. David Bland has some great quotes on this, but the minute you realized that what I need to do is learn, not build product, it really frees you up to say, "Oh my God, there's all this stuff I don't need to do, yet, I will need to do, but I don't need to do yet. So my first experiment was too much product, too much coding, too heavy. We were doing user interviews. We were doing all that stuff, but I was just taking too long and then it became three weeks and then we learned how to do it in three days. So everyone sucks at the stuff at the beginning. Your first interviews, you'll probably lead the witness more than you want when you're trying to do user research. You will maybe feel too stilted. You might be a little too robotic. You're going to be sticking to your script going in a little bit too much. And then you look back and you go, "Huh? I got all these superficial answers. I don't feel like I could use any of this stuff." And then you go, "Oh, because I didn't ask any follow -on questions. I didn't go digging." So now what I do when I teach the stuff is I say, "Go in with three or four questions at most. Ask 50 questions, but go in with very, very few and just keep on asking those follow-on questions. Don't let them get away with a superficial answer." It's not always going to work. Some people you're just never going to get the goods from, but you can pull a lot out of people if you go deep. So this stuff is hard at the beginning. And this is something that as a tangent, when I was teaching products all last year at NYU's Business School which we could talk about if you want to, but the students really struggled. Product looks easy from the outside. You go and you read Marty Cagan's book and it's like, "Oh, this is all common sense." It's hard in reality. All these techniques are hard in reality. So one, you have to have the humility to acknowledge that you're sucking at it at the beginning. Two, go out and figure out. Learn from others as to how do other people do it well. But then put it into practice and figure out your own ways for making it work. As you do that, you'll find that, "Wow, you're actually getting really good stuff. Oh my God, this stuff is actually now affecting our decisions. And we're moving faster, not slower. We're moving better as opposed to just blindly charging forward.

Holly: Yeah. Oh, I love what you said about it seeming easy from the outside. Especially when we read some of the thought leadership, sometimes you read the articles and it just seems like this is straightforward. But then you go and you try to apply it and you come into contact with all these challenges and things that make it harder to get where you want to go with it. How do you get students to recognize that?

Giff Constable: Some do, some don't. The trouble is it's an artificial environment. I think in some ways, it's easier teaching practitioners because one there's more pressure to do it. There's more reality. And everything in product is a craft. You have to be able to put them into practice. And you could try to simulate it in a class environment through cases. But to talk about a real example where I think it worked even better, when I got into meetup.com the only experiments that were being run were AB tests. And that was great. I mean, there was still a fight between product management and data science because it was taking a little too long to set up the AB tests and run them effectively. So there were PMs that were trying to shortcut that and then things would get rolled out, and then there'd be these ripple effects and data science couldn't figure out what the causality was and got really upset at product. There was a whole tension that I had to unravel. But there was a separate problem, which was that the only experiments happening were AB tests. And I think this is actually quite common out there at a lot of tech companies. I came in and I said, "You're waiting too long. Hey, PM's, we're a team." But I'm just going to be honest and say, "You're waiting too long." If it's an AB test that means we've built the thing. How do we figure out if this is a good idea before we've built the thing? And maybe an experiment needs a little bit of engineering resources, but when you're an 18-year-old company with a crap ton of tech debt, there's no such saying as a small project. There's just no such thing. So we have to do more by building less. We have to learn more faster by building less. So the teams embrace the idea. Really smart PMs working for me. So the pendulum swung totally the other way of, "Oh, we got to run experiments on everything." And then I had a new problem which was that everyone was running experiments in everything, and we were moving too slowly. So then I had to come in and say, "Okay, we need to use our judgment. We need to be really practical. What's high risk? Where's our confidence high where we don't need to run an experiment. We should just move as fast as possible using the research that we've done. We're not just flying blind. But not running experiment versus where does something feel high risk where it deserves an experiment? And how do we get those experiments scrappy? That was just a feedback process of letting teams try this stuff, letting them mess it up a little bit. The pendulum swung too far. The other way we brought it back. Right? And creating feedback loops. Feedback loops between me and the product teams, feedback loops within the product teams so that designers and engineers and product managers were challenging each other a little bit better about what was the best and scrappiest way to move forward, as well as trying to get feedback loops between the product managers themselves, which was actually the hardest thing at Meetup for me to do because all the teams were a little too much like islands. All of that needed to be created because when I was brought in, things were not working. They had worked better in past. They weren't working quite as well as I needed to at the time. Does that answer your question? I was trying to come up with a concrete example for you.

Holly: Yeah. I love the concrete example. One thing that what you just said made me think about is how much of being a product leader do you think is inspecting and creating the feedback loops?

Giff Constable: You're trying to figure out how to push great judgment down into the teams because a great product organization has good decisions happening at the outskirts, like down at the team level, not at the executive level. There's lots of ways to do that. Strategy is one. Hiring is one. Having great people who can make great decisions is one. Having strategy so that you have guardrails to make the decisions easier on the teams is another. But the other is creating feedback loops and systems in place so that people are learning and getting feedback on a constant basis and not being afraid of being a little wrong. What you want to do is have lots of little things wrong as opposed to big things wrong. Lots of little things wrong means we're trying, we're pushing the envelope. We're making some mistakes, but we're getting better. We're getting better. And that's what you're trying to build. You never really want that to stop. It's like you don't want to be making the same mistakes over and over again, but you want to be making new mistakes. Making new mistakes means you're pushing it. When you're pushing your craft, you're pushing the envelope, you're pushing innovation, but you want the mistakes to be small. So building systems, feedback loops, building a culture where people can be wrong, where people can challenge each other, where people can bring up things that feel might be stupid, but to also have a culture where people can say, "There might have been a better way to do this, or have you thought about this?" Great coaching is often in the form of questions. I'm not as good at this as I want to be. I look at someone like Christina Wodtke and I'm sort of in awe of the way she teaches and thinks and writes. But if you know, Christina and her books, Radical Focus and the like, but everyone's got to learn how to give feedback. Everyone's got to learn how to share advice versus asking a question back to the person who's struggling with something, and you're trying to create a culture where people are willing to be vulnerable and people are willing to ask for help. That was a big thing I was really trying to bring to the team was it's okay to ask for help. Matter of fact, I expect you to ask for help. I demand that you ask for help. If you've got into a problem, tricky situation, and you didn't ask for help, I'm going to chide you. I'm going to do this privately. I'm going to do this where you don't feel thrown under the bus, but I'm going to chide you. As a product leader, it was really important for me to model this to model asking for help.

Holly: It's hard to do.

Giff Constable: Ladders. Our career ladders are a little messed up. "Hey, product team, help me figure out a better skills matrix so that we've got more clarity up and down the chain as to what's expected of you at a different level, and how do you get to the next level." But help me, right? Or, hey, we're working through... This part of the strategy is a little Rocky. Let me pull you into that process." It's really fun for the junior, mids and seniors to get involved in that stuff. It's what they aspire to get involved in. They're not all fully ready to take it on themselves, but you pull them into the process. You get to model asking for help. You get to model collaboration. You get to model active listening. It took me a long time to learn how to do this stuff. I was bad at it earlier in my career.

Holly: I think a lot of us are. Maybe most of us. And it takes a while to realize that you're not so good at it.

Giff Constable: Yeah. But boy, if you could figure out how to lead by pulling people forward, but doing it in a way that is humble and really pulls them in, it creates a fun and great environment.

Holly: Yeah, it does. I've had the pleasure of being a part of that kind of environment too and it's the only way I like to work.

Giff Constable: What was it like for you? I mean, were there key takeaways of learnings when you had that as to what got it there or why it stayed there?

Holly: You know, I think not to copy you, but it is a lot about leading by example, a lot of being humble and taking moments where you've done something that you could have done better and using those as chances to show that we all are learning, that we're all making mistakes, that what matters is that we progress from their smartly and with humility.

Giff Constable: For a long time, there was a point in my career where a lot of my colleagues, when they first started working with me, thought I was arrogant.

Holly: I got that too.

Giff Constable: Yeah.

Holly: Yes.

Giff Constable: And what I started to realize is that was hard driving. Very action-oriented, very hard driving. I wasn't trying to come at things from a place of arrogance, but I was really trying to drive things forward. One of my key lessons there, I mean, yeah, I had to build self-awareness. I had to realize, this is my problem. I am creating this problem. It's not other people's problem. I had to learn how to be much more transparent about what I was trying to do and why. And I realized, especially at Meetup, which was the highest EQ high empathy place I'd ever worked. It was so good for me. I grew so much as a leader at that place because of this. We got in our way a little bit because of just how high empathy it was, but it was really fabulous for me. But I learned that you could be much more vulnerable than I used to think as a leader. Now, you could do that wrong. You can go at overboard. You can make it about you. You can really mess that up. It can't be self-indulgent. And you have to be careful about where and how you're being vulnerable. If you're freaking out, everyone else is going to be freaking out. So that's the wrong kind of vulnerability. But right kind of vulnerability is saying, "Hey, this is really hard." I had some situations where I just publicly said to my team, "Folks, this is going to suck for a little while and you're going to be a little pissed at me for a little while. Here's why, and here's what we're working through just so you understand the constraints. But we will get through this. I need your help on this. I'm going to have to work hard on this, but we will get through this." So it's finding that mix of like optimism and strength and vulnerability is really key, but just figuring out a way to be, one, self-aware and just a little more open about what's going on. That actually helped me kind of overcome some of that first impression of get his arrogance until they worked with me enough to realize, "Oh, that's not really what's going on." But it wasn't a great way to start off. Right? I needed to fix that.

Holly: Yeah, absolutely. I'm so grateful to one person in particular, one mentor of mine who identified that for me and gave me that direct feedback that, "In that meeting, Holly, your body language and the way that you spoke came off as arrogant, and people thought that you were insulting them." Having somebody actually tell me that so that I could work on it made all the difference." And you're right, it was very much like realizing that I needed to be more transparent with what was going on in my head and why I was asking the questions I was asking. Even thinking about things like my body language and my tone of voice and saying, "How do I take the question in my head and make sure that it comes out in a way that's non-threatening?" There's a lot of self-work, a lot of looking at yourself and realizing what you're doing poorly and admitting it and running your own experiments, trying to do better.

Giff Constable: I'll explain the reason why I'm going to ask this question in a second. But if you don't mind, what was it like first receiving that feedback? How did you take that in?

Holly: I felt mortified. Because I really want to be humble, I want to be liked, and I want to express my gratitude at everybody around me for all the things that they bring to the table. So knowing that I had come across that way was kind of crushing inside. So it took a little bit for me to study myself to a place where I could actually act on it.

Giff Constable: I know exactly what you mean. I think it was a wonderful thing what your manager did, giving you that feedback, making it actionable, making it specific, but just being honest with you. I think too many managers avoid doing that because they know it's hard to receive and it's uncomfortable, and people duck that responsibility. But when you actually in a kind but honest and direct way, help someone see what's really holding them back. It's so empowering. Like the uncomfortable in the moment, but it's so empowering. So for them to actually be a leader and help you and give you that feedback and then for you to absorb it, take it in and do something about it, that's what you want. I wish that'd happened more in the world.

Holly: Yeah. Me too. I aspire to create that kind of experience for the people that I work with. I don't know about you, but for me it was never natural. I didn't grow up in a culture where giving feedback was common around me. It felt uncomfortable for me to learn how to give critical feedback and push myself to do it when I have the knowledge in my head that there's a thing that somebody's not doing as well as they could. And I want to help them do it better, but I have to be direct sometimes. But just thinking about how I'm not doing them any services, if I don't tell them because they're trying to grow has always helped me. How do you overcome that?

Giff Constable: Well, just like the rest of this stuff, did it badly, tried to learn from others how to do it better, tried to learn from my own mistakes. You do get better. Being more self-aware, thinking more about the other person, less about myself. But I think a combination of trying to both iterate through wanting to improve. First, it begins with wanting to improve. You have to want to improve and you have to never be satisfied. If you're never satisfied, if you're never complacent with how you do these things and you sort of acknowledge, "Nah, I could be better at this." That's the start and then you both try things and you get out of your own head. You read, you talk to people, you learn, listen to podcasts, watch YouTube videos. People are talking about whatever it is. And then you fit the advice that we hear to your context and your situation. That's always critical with any advice is you've got to make it yours. It doesn't lie to every situation.

Holly: Yeah. So I'm thinking about what are the other things that I want to hear from you on? And I'm curious, what are the other companies that you sold?

Giff Constable: Well, neo was one of them. It was a company called Proof. So there were two that were tied together. So this company called Proof that Jeff Gothelf and Josh Seiden and I had started. So I'd come out of a startup that had two really amazing years. I was doing metaverse, virtual world's work, which nowadays we call metaverse work. And it was before it's time back then. And I suspect it's still before it's time right now. But we had two incredible years, high growth, going up like a balloon, raised a bunch of money, and then it hit the skids during a financial crisis. I also realized that it was just before it's time. And I then started the company and put a really intense year into it and we were struggling. We had some things that we can convince ourselves that we were getting towards product market fit like we were ostensibly doubling month on month, but just, it was a really uphill battle. And a VC that knew my co-founder and I. My co-founder was a woman named Liz Crawford, brilliant engineer. We got pulled into a little startup called Birchbox, which was maybe just about 20 people at the time and they were doing really well. We looked at them and said, "Look, they rocket ship." We looked at our struggle and we said, "Okay, they've got some lightning in the bottle. We don't. We're doing the wrong thing." Liz ended up joining and becoming their CTO and helped them grow over a lot of their years of success. I came in, I was doing a whole bunch of product and design work for them. I've totally tangented off your question.

Holly: No, that's okay. I'm interested to hear anyways.

Giff Constable: I realize that there was a lot about product that I needed to learn because in the startup world, you just do stuff.

Holly: Yes.

Giff Constable: You just get stuff done. But what I realized is there was a lot to learn from the design community, from the engineering community and even sort of this very nascent product management community about how to do this stuff better. So I was like, "What's the fastest way for me to learn this other stuff?" As I say, I don't always love being a consultant. I knew that actually from a consulting perspective where you just get to have lots of projects, try different methods, you get really steep learning curves really quickly. So Jeff Gothelf and Josh Seiden and I... They became famous for writing Lean UX and Sense & Respond and other things. But we started this little consulting company and we were doing different projects, but I was learning a ton from them. I learned more from them about UX than anybody. Neo came knocking. Neo had been a roll up. This was a consulting company. It was mostly an engineering consulting company, software engineering consulting company. They were really trying to get into innovation. They had pulled Eric Reis into the company, but they didn't have people that really understood how to apply Lean startup methods. That's what the three of us knew really well, and some of the people we pulled into our orbit. So they basically bought our capability. I ended up becoming CEO of Neo and we had our ups and downs as a consulting firm. We did really great work. We had some structural problems due to how the company was financed and pulled together that ultimately led me as the head of the company realize, "Okay, the best thing for the owners was to sell the business." So we sold that business to Pivotal. That was the second part of that journey.

Holly: Yeah. I'm super curious since, I obviously run a consulting business myself, what were the problems that you came across?

Giff Constable: You know this, anyone who's in consulting knows there's two parts to having a really good consulting business. Well, three. You've got to do really good work. You've got to be able to bring in work and you've got to manage your economics really, really well. And you've got to know what kind of economics work for you. Are you a company? Are you very expensive, very high end, the McKinseys of the world, the BCGs of the world? Are you going for something that's lower costs and higher throughput? Do you have a lot of very senior people who are expensive in which case you have to structure certain kinds of projects? Or do you have a lower cost labor where you've got a lot of leverage there? And of course, do you have a system where you're bringing in the right amount of business? I've learned over and over again as a product person and here as I'm running a company, you got to get the whole business model working together. It's not just about the product, it's not just about delivery, it's how you make money. It's the economics. The whole thing is a system and it's got to work together. So Neo, we were doing amazing work. We had great clients. We had incredible people there who have gone on to do amazing things. The alumni network from that place is fantastic. We were being looked at by a lot of the best consulting firms in the world as the leaders. And doing digital innovation and business model testing, but we had this problem. We had this problem where the owners of the business, which was this big Japanese fund had rolled up a few consulting companies for a company that wanted to be lean. It was very un-lean in the beginning. It rolled up a whole bunch of companies. It created all this capacity and then it changed the names of these firms and some of the founders of those firms had cashed out and they had left. All of a sudden there wasn't a big enough brand. There wasn't enough flow of work coming in, and we started having utilization headaches. So you combine utilization headaches, and then we had an incentive problem. All product people understand that incentives are everything, whether it's watching the behavior of your colleagues and what they're doing inside your company or watching what your customers are doing and what are the incentives you're putting in place for your customers. So we had an incentive problem where the company was wholly owned by this big Japanese fund. A lot of the really senior people didn't quite have enough of a stake in its successor failure. So they were really interested in the work. They wanted to lean into doing great work, but not getting the great work. So we had this sales problem. So we were bopping back and forth. I had to do some things. I had to shrink it, spin off a few pieces to get it to profitability. We were bopping back and forth in profitability, but there was just fundamental problem. There was also a bunch of debt layered on the business that made it hard. So the capital structure, the incentive structure of the business was a really hard system. And because we didn't fully control, it wasn't like the senior people were the board. We were the MDs and the owners. It made it hard to change. And ultimately, again, my diagnosis was, this cannot be fixed without a complete restart and a total recapitalization. That's probably not what the owners want. So let's find it a better home. And that's what we did.

Holly: Yeah. Oh, it's so interesting to hear you talk about the incentives and the importance of those because I think that's also something that I see within product organizations is how is the incentive structure set up? Is it set up to make everything work properly?

Giff Constable: Yeah, to work properly, to get people to take risks or not take risks. If people say, "Oh, why are people taking risks? We aren't innovating." It's because of the way you're doing OKRs and the way you promote people. You're basically steering everybody to take high odds, low risk projects.

Holly: Yeah, exactly. Well, I think we're almost about out of time. So I like to ask people at the end just if they have any final advice for aspiring product leaders or early career leaders?

Giff Constable: Oh, open-ended question. But we talked about a bunch of different stuff that was interesting today. The thing that I'm working on right now, I'm in the middle of trying to create essentially a finance program for product leaders, whether they're PMs or designers or engineers. I have a weird background early in my career in between startups. I also was a technology investment banker. So I was doing a lot of M&A and IPO work. So I got very deep in finance because of that. And I've realized over the years that it's a real sort of glass ceiling skill for a lot of people in product. They know metrics really well, but they don't know finance quite well enough. Finance is this really critical skill and language at the senior level. It's the language at the board. It's the common language at the C-suite. And I've seen too many folks in product. And again, I use very broadly. Engineers, designers, and product managers. I've seen too many really talented people struggle to succeed or struggle to break to the next level because of a lack of understanding there. And the biggest thing that I've been pushing people is you don't even need to be that deep into do accounting, but you need to understand how businesses are valued. You need to understand how metrics, product metrics and finance connect. You need to understand how to communicate in numbers. So investing in that, figuring out ways to invest in that by working more closely with your finance organization, your C-suite. You could do a lot just inside your company, just by expressing interest in putting some work into it. But really investing in that I'd say is a core skill. Over the next few months, I'm going to try to add something to the field that hopefully makes it a little easier and better, but we'll see how long it takes me to do.

Holly: That's exciting.

Giff Constable: That's the big thing. I think revenue models, business valuation, how that connects to product is not something I find our field talk about a lot. And I think it's critical, especially if you want to think like a product leader.

Holly: Awesome. Well, that's really great advice. So where can people find you if they want to learn more about Giff?

Giff Constable: So Twitter, I'm @giffco, G-I-F-F-C-O. I have website, giffconstable.com with a blog there. The blog is sort of off and on. Probably going to post something in about a week. But right now, as I'm leaning into this current project, I'll probably be a little quiet. I probably will start getting more prolific again. I'm not sure if that's going to be a few weeks or a few months, but between Twitter and my website giffconstable.com are the two best places. Or LinkedIn. I'm on LinkedIn.

Holly: Awesome. Wonderful. Well, thank you so much for your time today. It was so much fun to talk to you, Giff.

Giff Constable: Oh, Holly, thank you so much.

More Posts