Pivotal Tracker, Notion, and Product Plan recently banded together to create The Product Stack. Our goal is to foster a community where product owners can stay on top of their trade by sharing the processes and tools they use—at every stage of the development cycle—to manage their product.
A few weeks ago, we held our first event to a packed house of over 100 product managers at General Assembly’s beautiful new downtown LA location. Our moderator for the evening was Suzanne Abate, the talented CEO of the Development Factory, and host of the podcast 100 PMs.
The theme of this event was, “What does it take to plan, execute, and measure your way to a customer-centric product.” Suzanne interviewed each of the three sponsors in turn—(you can watch Product Plan co-founder Jim Semick’s interview here)—and then led a panel discussion on the future of product management (which we will post in a few days). In this video, Dan Podsedly, Tracker’s GM and “godfather,” talks with Suzanne about
The Product Stack: Dan Podsedly Interview from Pivotal Tracker on YouTube.
For your reading pleasure, here’s the transcript of the interview:
Suzanne: Please welcome—am I going to do this right—Dan Podsedly. I did it. From Pivotal Tracker, everybody. Dan, all the way from Chicago to be with us, by the way.
Dan: Thank you, Suzanne. That was quite the intro.
Suzanne: Would you like a seat?
Dan: I will sit.
Suzanne: OK. Do we have any Pivotal Tracker customers here in the audience tonight? Can I get a show of hands?
Dan: Woo hoo!
Suzanne: All right.
Dan: You used to be? I want to talk to you afterwards.
Suzanne: Save it for the Q and A.
Dan: No, really I do.
Suzanne: Welcome Dan.
Dan: Thank you.
Suzanne: The word on the street is that they call you Mr. Pivotal Tracker.
Dan: I’m not sure what street that’s on.
Suzanne: It’s “the street.”
Dan: No, it’s “Father Tracker,” or the “Father of Tracker,” which is actually incorrect because I wasn’t there when it was born. I was there when it was born and then neglected. I rescued it. I nurtured it. Therefore, I’m more a godfather, a stepfather. That would be the better way to represent my role.
Suzanne: So we’ll call you godfather for the rest of the interview.
Dan: Sounds good to me.
Suzanne: Great. Maybe we can just start by taking a minute and helping us to understand all the layers to the Pivotal empire. Because there’s Pivotal Labs, and there’s Pivotal Tracker.
Dan: It’s the first time I’ve heard it referred to as an empire, but we’ll take that. I’m a godfather. I am from the Pivotal empire. I’m not sure that those go together well, but I’ll take it. Who here has heard or Pivotal, outside of Pivotal Tracker? What our company is a bit of a mouthful now. We started as a little consultancy in San Francisco. We were building products for and with startups. That’s kind of where Tracker began. That was Pivotal Labs. We were very much into, not just building something, but teaching how to do it. Our method to the madness was very deeply rooted in extreme programming as a thing, as a methodology.
Small teams, pairing, pair programming, test-driven development, the whole thing. Cross-functional teams before they were called cross-functional teams. That was just something that made sense to us. We built Pivotal Labs out of that. We grew because of word of mouth because we got positive reaction. Our customers were happy. They told their customers. VC started sending their portfolio companies to us to eliminate the technical risk and to really teach how to fish. We built that. That’s Pivotal Labs, so that’s still part of Pivotal except it’s now I want to say in like 12, 15, maybe more offices around the world, including here in LA in Santa Monica.
We also have a pretty big product called the Pivotal Cloud Foundry. It’s a pass right. It’s an application layer that sits on top of Amazon, Google, Cloud platform, Azure. You can run it internally on VMWare. That just makes it really easy to deploy, scale, manage apps. You can literally deploy rails app in like 30 seconds without doing anything. You can move between Amazon, and Google, and Azure. You don’t have that infrastructure lock in so that’s a big piece of that. We have Tracker. We’re a fairly small piece. We’re like a little island. Most of our team’s in Denver. We operate more like a fully functional startup within this larger organization, but then Pivotal I think has some other things like a data, some data products. I might be missing something, but that’s Pivotal in a nutshell. We’re a few thousand people now.
Our roots are very much still with the startup community, and although we work with a lot of enterprise customers now, what we’re really bringing to them is—I mean it’s like leveling a field. Every bigger company’s under disruptive threat, right? There’s an Uber for whatever in your industry, for your industry. They realize that so they’re coming to us to learn how to be like a startup, how to operate more efficiently, how to do continuous delivering and actually ship on a regular basis, how to form teams, how to just execute. That’s us in a very long nutshell, or a large nutshell.
Suzanne: A long, large nutshell. What is Pivotal Tracker, actually, as a software? Jim spoke a little bit about wanting to keep the boundary away from project management. How would you describe what your product is exactly?
Dan: Sure. Generally speaking in terms of categories. I guess we’re a project management tool, but that sounds really boring, right? When people ask us like, “Oh we’re just a project management tool.” No, we’re not. We’re a focused, precision, execution tool. That’s what we are. We are, right. Really it’s like this very specific thing. Put together a small team, a cross-functional team: obviously, project manager; a certain number of engineers—not too few, not too many. Throw in UX, throw in data science, maybe an exploratory tester. You’re like, OK, now you have a team. Tracker is where the backlog, the single backlog, lives for that team. It’s the thing that gives them their mission. It’s very visible. The product is very optimized for visibility. You look at Tracker. You’re always on the same page. Everything is right there.
This is your backlog. This is who’s working on it. We are collectively pulling from that backlog rather than having a manager assign tasks to an engineer, and then asking, “Where’s your task and how many hours remaining?” It’s just a crisp, clean focus backlog optimized for collaboration by a cross-functional small team with a single mission or clear milestones.
Suzanne: First of all, the Development Factory is a long-time customer of Pivotal Tracker. We love them.
Dan: Thank you.
Suzanne: The other thing you might now know is that in my class, when I’m introducing to an up-and-coming product manager, this concept of problem solution fit, I always include Pivotal Tracker among the slides. I’m curious to hear your definition of what is the problem and why did a solution like Pivotal Tracker need to come about in order to solve it specifically.
Dan: I could maybe revise history a little bit and make it sound like 10 years ago we were doing this thing they call lean product management with problem-framing invalidation, and market fit, you know all that stuff that of course you would do today if you’re starting a new product. For us, it was more about solving an internal need—a very specific one. We needed something very tactile, very visible. At the time, Trello wasn’t around. JIRA was pretty early days. The space of project management was very different. Clunky, heavy, hard to use—like, where is stuff? Everybody’s got a different view in that tool. We just wanted something that was as crisp as having just a list of cards on the wall, right there. Very visible. Very radiant. Very tactile, and canonical. This drives the team. People see it. It’s visible. It’s around them. You’re working in a story but you know, because out of the corner of your eye you can see what’s coming up.
You’re getting close to that release, to that milestone.
Suzanne: No.
Dan: Sorry.
Suzanne: No. You’re never getting close.
Dan: You’re right. Never. At least you can see it, right? We wanted to represent that kind of very visible, tactile thing, but obviously on a computer because sometimes the cleaners would come and mess up the cards, or somebody was working from home. Just really taking that, making that come to life as a piece of software that we could all use that would drive our work. That would make it visible, and that wouldn’t require a lot of hunting for all this stuff that is typically stored somewhere in a project management tool.
Also, we had to learn how to write Rails apps, Ruby on Rails, because people were starting to pay us to build Rails apps for them and we didn’t really know much about Rails. We built it for the sake of the learning experience of the technology. We built it because we needed it on our projects, and then it served to sort of feed itself. We had sort of the first iteration of Tracker in Tracker sort of driving its own evolution as a project.
Suzanne: It’s interesting. This is a common way that product managers can end up with jobs because they suddenly realize, “Oh, I’ve been left to babysit this little pet project that we’ve created.” Can you talk a little bit about the journey from an ad hoc internal tool that somebody had to look after into pointing it out toward a market and managing it as a customer-facing product.
Dan: That was a few years of my existence, right? I’m sure many of you have been around in a consulting company where you’re essentially selling your hours, your services. You’re all about billable time and utilization and many consultancies also develop products in a similar way. You have a need. You solve for it yourself. You built something and then you start getting into this like, “Well, that’s interesting.” We have a thing that could be a product, but you have to think about it different because you’re so optimized for thinking about those billable hours. You throw your beach resources at it; not resources, people. “Somebody in between projects, go work on Tracker.”
That’s what our tool was for a long time. It was a side thing for me, too. I was out there, working on these client engagements, whether it was in our Pivotal offices or at some of the other bigger companies at the time. Tracker was my little baby side thing that I started to care about deeply. I kind of kept sticking with it. Nobody was actually telling me, “You need to PM that on the side.” First of all, I was an engineer. I knew nothing about product management. What does that actually mean? It means you drag some stories around in the backlog and then these engineers will do things if you just move something up. That’s awesome, but I started to get kind of giddy with that. It would be really cool if Tracker could do X.
I’m just going to add a story for it. We did it. The button should be blue and it should be on the left. It’s like completely wrong, right? It started to get interesting and as we started to get this sort of organic traction around it because our customers would get hooked on it, even though it was super simple, but there’s something addicting about it. It drove people to behave a certain way. It had sort of a gaming, gamification aspect to it that wasn’t necessarily intentional. Things turning green as you get your stories accepted. Your velocity going up. These started to motivate. People wanted to stick with it and so that, I started to understand the satisfaction that you get from being a product manager and seeing something that is sort of like yours.
Whether it’s your real baby or it’s just your job to take care of this thing, you get attached to it. You start to really feed off the positive feedback. You’re seeing more people use it and you’re like, “Oh, it’s actually solving their problems. It’s making their days better.” That’s really satisfying, which is what then motivated me to gradually become more of a full time, or my role started to be more full time. Traction grew. My interest, just from that experience grew. Obviously, now we start to think about, “Well maybe we should make some money with this because it’s a disservice to provide a tool.” Even though it was still just a free tool, a lot of people around the world were using it at that point. We just sort of opened it up, like we made it really hard to sign up and then everything you had to sort of figure out. There’s no onboarding. There’s no help. Nothing.
People started to use it because of this word-of-mouth thing. Clearly, at some point we’re like, “OK, we can’t just keep having people on this, but if we don’t keep people on this all those companies out there that have started to rely on our product as a daily mission-critical tool.” We had some outages because it was starved, we were starving the support for it so there were some outages and when outages start to happen… Now Twitter was already around so people started to bitch on Twitter. It was embarrassing. We were almost dragged into doing the right thing. Saying, “OK, maybe if we turn this into a product,” and this is just me doing it on my own with no support from the rest of Pivotal. I just had to figure everything out. What does it mean to be a product. Oh, well you make money. How do you make money with a SaaS product. What do you need to do? What is a merchant account, by the way?
Gateways. Now we need proper onboarding, and credit card, and PCI compliance. Just all this stuff, right? I just kind of figured out, and again it was continually driven by more and more people using it. More positive feedback and more just desire to do more for them and to be a tool that can help thousands of teams and companies around the world. Just became a natural transition for me.
Suzanne: Did you lose customers when you turned on the pay wall?
Dan: Good question. Thinking back, we lost about 20% of our active customers. Which, we had no idea what to expect. When we first turned on pricing, we were watching Twitter going, “Oh my God, what’s going to happen, right?” Interestingly, most of the feedback that started coming in, it was a bit like, “Wow, why is it so expensive for this many projects or whatever,” but most of it was like finally, finally they’re going to treat it like a real product and we can start relying on it. Finally, I don’t have to hide the fact that we’re using it at our company because now we’re going to pay for it. Now it’s like a real thing and now it’s going to get the support that it needs. The feedback was overwhelmingly positive. We only lost 20%, which at the time we thought was a pretty small loss, all things considered.
Suzanne: It’s an interesting parallel to the story that Jim was sharing. They had this very scientific reverse engineering process. You had, as you described the much more scrappy, we didn’t know. We were figuring it out on the fly, but in both cases I think a great testament to if you create a product that has true value, you can transact value through retention, through revenue, through referral.
Dan: Yes it may actually succeed despite your best efforts to stop it.
Suzanne: On the topic of execution because project management, process management is about execution. That’s what you’re about. What do you think makes a great development team?
Dan: Yeah and I think we’ve learned a lot about this over the years. I think we just always had a fundamental sort of belief that there is power in a small team, first of all. When you talk about teams, I think there’s some pretty clear situations of what is a team, and what isn’t a team. To me, and even beyond the numbers. Obviously 30 people, to me that’s not a team. Although, I take that back. You can be a team, but at the execution level you can’t all be sort of focused on one thing. One product manager can’t product manage with a group of 30 engineers, for example. For me, a good software execution team is a PM, obviously.
In our world everything’s pairing. We don’t even count people in ones. At least engineers, which is kind of weird. I don’t see two of you. I see one pair. We count pairs. A proper team, as far as I’m concerned, is 1 PM, two to three pairs of engineers, a UX person, and then maybe some of the roles right, to help with some of the research or maybe testing. But they’re embedded and it’s no larger than I would say 8–10 people, max. That’s a beautiful thing. That’s a beautifully executing team as long as their priorities are clear. I think what we prefer over, even though it is possible to take a person or team of 10 people and start on a daily basis assigning tasks or issues, or whatever to individual people.
That’s hard. That’s messy. Instead it’s like, have your priorities clear. Own everything collectively. The code base. Anybody can take the next story issue, whatever you call it, and just work together to see it through. This team is inclined to work together. There are no heroes. There are no individual contributors that stand out above the rest. That’s a poison atmosphere. We are all in it together. We’re one team. We sometimes play together. Maybe we go drink together once in a while. We’re bonded. We have empathy for one another. Then it’s like going back to what the PM does. Our priorities are clear. We understand the vision, the big picture, but we also understand what is the next three things tactically, right?
We celebrate our wins together. All that. I can keep going, but that to me is perfect. Then you scale up organizations with these sort of individual small cross functional teams.
Suzanne: Do you have an official title at Pivotal?
Dan: Do I or do people?
Suzanne: You.
Dan: Yeah it’s been kind of very fuzzy. I was the general manager, now I’m the whatever VP, Pivotal Tracker, which is like, OK I’m the VP for Pivotal Tracker.
Suzanne: It’s very mysterious.
Dan: My role has been partly product, right, where I am still acting as the head of product and we have multiple PM’s and designers. We have I think three PMs, three and a half because one of them is an engineering director that also wears the PM hat for some of the infrastructure and dev ups pieces. We have three UX designers. I manage them, but then I also manage the guy who manages all the engineering, and then I also manage a support team. I still try to keep my hands across everything, so therefore my title’s always kind of fuzzy and broad.
Category: Community
