Trust and Transparency

Suzanne: We’re just getting started.

Dan: Yeah, we’re just going to get started here. My name is Dan Podsedly. I work at Pivotal. I’ve been with Pivotal ever since the beginning of what it was previously called, which is Pivotal Labs, a little consultancy in San Francisco back in the mid-2000s. I started as one of the original I guess principals but mostly as an engineer working on projects where we built software for other the companies. Over the years have done a lot of different things, a lot to do with introducing an agile culture to teams that were new to it, whether it was a startup or a larger company. Over time, I got involved with our little internal tool that we built for these projects that we worked on for our clients, Pivotal Tracker.

That became gradually my full-time job and I went from being an engineer working on the product to being the part-time product manager to being a full-time manager when we launched it as a real product, when we went from a tool to a product. I’ve been doing that ever since then which was I want to say about five, six years ago when it became a product. These days, I manage it as a product. I’m the VP and general manager which means I manage every aspect of the product, but I’m very heavily I guess biased toward the product aspect of it. I am the head of product. I manage multiple PMs and designers. I also indirectly manage the engineering team as well as the business aspect of the product and the P&L.

Suzanne: You said a lot about Tracker. I want to start by going back into your path. Did you begin as a developer? Was that your original marketable skill?

Dan: That is where I began. Right after school, I got involved in some really interesting software projects as part of the co-op program I was in during school. That’s what I was doing for years. I worked on a number of different projects across different companies. When Pivotal began, and this is actually how I met some of the other principals and founders of Pivotal Labs, we were all working on these big OO projects that were trying to replace legacy systems because this is about the time when Y2K was happening. This is when we discovered agile and at the time, this new emerging methodology as it was called, extreme programming which involved pairing and test driving. That’s what led me into my current situation in Pivotal. I was a developer for a while, on client projects within Pivotal and then started to pick up the PM piece as part of the Tracker experience.

Suzanne: Was Pivotal just there from the beginning of your career or you worked as a developer for other organizations before? I’m sure it’s hard for you to remember life before Pivotal at this point.

Dan: It has been a while. It definitely has been a while. I spent a number of years outside of … just in the industry. I started as a co-op student at a bank in Toronto. I worked at, what was it, a big dog food company in St. Louis as a developer on some of their projects there. I also worked at IBM, through IBM on a number of client projects including AT&T in New Jersey. I think I had about seven or eight projects under my belt as a developer primarily before joining Pivotal.

Suzanne: We did an interview with some of the folks from Pivotal Labs out at the Santa Monica office here on the show. We’ve talked a little bit about it, but Pivotal Labs is a product consultancy. You were part of the founding team of that product. It’s huge now, Labs. It’s everywhere.

Dan: That’s right. It is. Labs and especially the larger Pivotal, right? There’s a little bit of confusion around what Pivotal stands for. In my mind, the real Pivotal was Pivotal Labs which is what introduced or came up with this culture of how we work, very strong emphasis on small teams. We were doing this cross-functional balanced team way of building software even before those terms existed. It just made sense to us that the best way to build software is as a small team working together with everybody having a shared understanding of what’s important, what we’re working on today, where we’re going. That was the basis of Pivotal.

That’s what really made Pivotal what it was, it’s forming these teams, bringing some of these XP or agile methodology approaches to it as well, especially the engineering practices in particular. Test-driven development and pairing, that was huge. We brought those together. If you take TDD or test-driven development and pairing and do that as a small team with clear priorities and a customer in a room experience, great things happen out of that. We had lots of success with that model, just focusing on those basics. We used different languages. We did Java. We did Ruby. We did a bunch of other things, but the common element was the small team, the highly involved product manager, although it wasn’t even called that at the time. At least we didn’t refer to it as a product manager. We called it the customer.

That concept of the customer becoming the product manager, working with the customer evolved over the years. The basis still remains at the larger Pivotal now. We have thousands of people in the company. It isn’t just Pivotal Labs anymore, Pivotal Labs the consultancy, but that’s a big part of it. I think they’re up to about 1,000 people, if not more, spread around the globe really. I think there are at least 18 to 20 Pivotal Labs offices these days across all the bigger cities. The core culture is still very much about the small team with clear priorities, with everybody just pitching in as they need, working together, pairing, and not just between developers. Now you see PMs and developers pairing. You have designers pairing with developers and PMs. This is what made Pivotal what it was.

Now we have all these other products within the larger Pivotal organizations. It took a while to get that culture to spread and be perceived as the right way of doing things beyond the Labs part of the organization. Now it’s been embraced really everywhere. Every team at Pivotal is now working the same way that we started working as, as that little Pivotal Labs in that little, tiny room above, I think it was a psychiatrist office in the old building in San Francisco.

Suzanne: I don’t want to take for granted that everybody listening understands, number one, agile. I think agile is hard, and even organizations who are agile or purport to be agile struggle with that. We can talk more about that. For teams doing it the right way, as you described, this small-teams approach, this integrated approach, why is that the right way? What was some of that foundational ideology? Take us back in time to what was so groundbreaking about that.

Dan: I think it’s worth clarifying. There is no right way. I’ve been in this Pivotal world for years now. I have a perspective that’s been honed by that experience. From that experience, I have some opinions about what works and what doesn’t work, but it doesn’t mean that it’s the only way of doing it. Again, from that experience, from our history here, and even the word agile. I don't know whether it’s lost its meaning or it’s become such an overloaded term that it could mean so many different things.

Suzanne: What does it mean to you?

Dan: For me, I think the difference if you look at where Pivotal has been and what it really tries to encourage. To be honest, a lot of it is just more of the same. We’ve had the same mental model or the same perspective for years. A lot of it is just common sense. Bring common sense to the table and don’t forget common sense because sometimes we do forget that. Sometimes we just do things because we’ve always been doing it the same way or because the methodology or the book that we read about how to work told us to do so. For us, it’s just really been … We’re not smart enough to know how to do it right so let’s just slow down and let’s break everything down into small pieces. It’s really hard to work or to organize into a team of 30 people. How do 30 people work on some large project? We don't know. It’s really difficult so let’s not even try.

Let’s just break everything down into simple, small components. That’s true in development. When you're writing code, it’s all about finding the smallest unit of progress, whether it’s a little function or a little object or whatever it is. We just take the same approach to projects or building products. Break everything down until it’s really small and it becomes really easy.

Teams have to be small in order to be able to execute and collaborate together. People working by themselves, it’s really easy to do work by yourself. If somebody gives you some clear instruction, you can go off in a corner, whether it’s writing some code or preparing some documents or whatever. Most software products are bigger than the individual person so we have to work in groups. There’s just a lot of communication that has to happen when building something bigger than what one person can do, especially around software, so we have to work as teams.

We simply don't know how to operate as a team of 20 or 30, so we make sure that everything is broken down into teams of 4 to 6. You have one person who is empowered to make decisions about what to work on. This is typically the PM, prioritizing a backlog. We have a relatively small number of developers because you can’t have more than a certain number of developers working out of one prioritized backlog. It gets crazy. You start to have people stepping on each other’s toes. It just gets hard to manage. Really it’s that art of the composition that we started to get good at, and it’s decomposing everything into these small elements.

I would say not trusting ourselves with the code that we write, therefore we write tests first because we don’t trust ourselves. We don't know how to write code that has no bugs or that actually does what it was intended to do. Therefore, let’s write the test first, to make sure that we’re going in the right direction. I think there’s a common theme of making things as simple as possible, as small as possible, writing down the intent before we go off and write some code, etc.

Suzanne: It’s interesting because a lot of people are connecting now with this idea of validated learning. It’s a framework or an ideology that’s gaining popularity in the context of management, in particular product management. In a lot of ways, it’s essentially the same foundational principles that agile has been running on in this parallel universe but it’s always been specific to software delivery methods of breaking things down, incremental progress over time, testing to see what works and then making an adjustment based on, oh, that didn’t work as we had hoped or that wasn’t in fact the right output, etc.

Tracker which is this is where you live now. I don’t want us to get lost in the Pivotal empire of it all. Tracker is a product that was essentially incubated inside of Pivotal Labs. That’s how it came to be born?

Dan: Yeah. We built it as just a tool that we used ourselves because it just made things easier. It made everything more visible to the team that was building some product for a customer. It replaced just a manual way of doing what Tracker does today which is representing the stories that we were working on this week and maybe the next week on a wall with a bunch of stickies. We just took that and said, okay, we need that but in a software version. At the time, there was really nothing else like it. I think the main difference, and this also goes back to your previous question of what is it that we value as Pivotal? What is agile to us?

I think compared to what a lot of other teams do, we have observed or have experience with, is there is almost a level, we operate on a level below what is typical even on other agile projects or in other situations like a lot of scrum teams. A lot of scrum projects will break things down to a level of granularity where at the lowest level of collaboration as a wider team, you're talking about some feature or some problem that may take days or weeks to make progress on to get to some closure, to get feedback on.

We believe in going one level deeper or lower and breaking those things that normally take a week or two into stories that take a day. Breaking the project down as the entire team, including a product manager, to a level where every single prioritized item becomes something that can be completed in a day. Now that process could get there. It’s pretty hard. This is I think the biggest learning challenge for people new to our team or other teams at Pivotal, especially product managers who are used to operating at a different level of granularity. We see an opportunity. We maybe are talking about a feature that we’re building for a customer because we know it’s going to solve a problem. We’ve broken it down to these really coarse grain chunks and then we give that to the development team. That’s how it’s normally done.

Two weeks later, you get to see that big thing built. You get to provide feedback. For us, that’s not enough. The feedback loop around that is too short, and so we as an entire team, including the PM, the product manager, break it down to … Instead of having one feature that the team is working on for a week, we have a dozen stories. Tracker came out of the need to operate at this lower level or this finer level of granularity because it got really hard with the stickies and the cards on the wall because every single feature, every single project that we had in play would end up just going through dozens and dozens and dozens of these cards. Every day you would discover a new one because we were all operating at a level of detail that was great. It uncovered all the assumptions early. We learned a lot from the conversations, through the attempts to break things down to these finer grade incremental stories, but it got really hard to manage.

We needed a tool that made it easier to manage a backlog at that level of granularity where you’re really getting into the details and you have the shared visibility at that level of detail. It didn’t bog down and every new story that you had to add took five steps because you had to go to some other page and then you need to go to another page to make a change. The intent was just a simple, shared, very visible to-do list but at a very fine level of granularity. That’s essentially what we built. We built this super high-grain to-do list that was easy to collaborate around and that was visible to everyone and where everyone had the same understanding and the same view of what was in that to-do list because it drove the execution.

That’s the super long answer to your story. How did Tracker begin? Why did we build it? It was essentially that. There was nothing else like it. That fine grain level of collaboration is something that is pretty hard to support, unless you really embrace that and build a tool specifically for it.

Suzanne: I think the person who was tasked with manually writing all these micro stories on to cue cards was probably the true gene inception point of Pivotal. How can we make it so that I don’t have to write with my hand anymore? It’s cramping up.

Dan: Actually, you're absolutely right. It was. That person, his name is Alex Chaffee, was acting as that PM in the room for the customer. I think he did get tired of writing all those little notes. He wrote it. He actually wrote the first prototype of it. I think it took a week or two and then we actually started using it. It just made his job easier. I think that parallels a lot of how we’re trying to work these days. I really believe in that as a way to build product, when you have the opportunity, is solving a problem that’s very near and dear to you. If you have a problem and you can solve that well, that’s a great way to validate something.

We over the years as the Tracker team, we maybe went away from that a little bit. As we became a product for the masses or for the wider community, we had to start making prioritization decisions and product decisions based on what the market needed or what our customers and the aggregate were telling us. Maybe some of the ways that we solved problems or some of the problems that we ended up solving with the product, they weren’t quite as dear to us, and so there we had to engage in a lot more of the normal kind of customer validation or product validation with research and prototypes, etc. It’s really great when you have the opportunity to solve your own problems. These we call dogfooding now. It’s drinking your own champagne or [crosstalk 00:21:13].

Suzanne: That’s a much nicer term.

Dan: I know. It’s a much nicer way of saying it, but it’s essentially the same thing. If you can solve your own problems and your problems they’re not super unique where only you have them, in which case you're just building an internal tool, but if it’s something that you can help model. This is how we work. We think there’s an opportunity out there because lots of other people have the same problem and if we can solve that problem for ourselves, then it’s a good basis for something that will do well out there in the market because you’ve had that level of validation. We’re coming back around. As we look toward taking Tracker into the future, there’s obviously a lot of opportunity there especially around supporting the modern grown-up balanced team with more specialized roles, how do you support such a team into the future?

The good thing is that we have a lot of the problems that every other grown-up cross-functional team at scale, when you have 30, 40 people across multiple teams all working on the same product. It’s great because we get to solve these problems again and we get to go back to where Tracker began and drive it from internal need as if we were just a consultancy building a tool for our own needs but have this larger impact with the product because there’s this larger audience.

Suzanne: Let me just package up what I’ve heard you say so far and then come back into Tracker more specifically. The first step was how do we go from large-scale teams into smaller-scale teams? That was the first adjustment, is being more effective when we work in smaller groups. That same mentality of reducing in the form of stories. What I think I heard from you is what we sometimes refer to as epics, which is most of the time when we sit down to write a user story as a product manager or product owner, we start with what we think is the smallest thing and then we actually discover, oh wait, this is 19 jobs rolled up into what sounds like a succinct statement. As a user, I want to be able to view reports so that I can see my company data. It sounds articulate. It sounds like a user story. Inside of that, there might be 10 different kinds of reports, a bunch of database level updates that are required.

Is that specifically what you're talking about, is instilling this idea of taking a bigger story and then learning how to unpack it into smaller bits?

Dan: Yeah. I think it shows up on multiple levels. It isn’t just like that one level where we’re talking about as a user, I want to be able to do so that … and then breaking that down into smaller pieces. That’s one of the challenges. How do you go from that to the smaller pieces? If you look at, I don't know, a bicycle, you say, well, there should be a bicycle. As a user, I should be able to jump on a bicycle so I can go to the store and get some milk. Yeah, okay, but there’s nothing right now. What is the very first thing that we can imagine? What is that minimum desirable feature or viable feature that will get us to the store but without all the bells and whistles? Because if you imagine a bicycle, there’s a lot of stuff going on there. Does all of it have to be there? Actually no.

Breaking down the process of the bicycle coming to be is really interesting because you get to ask questions about assumptions and evaluate things, whether there needs to be a bell. Each of these things is an opportunity to produce scope so you can actually get to releasing something interesting that you get quality feedback on earlier. The decomposition becomes a lot of what we do. I think that’s where there’s a lot of opportunity to learn and hone skills over time as the product manager. Going from the understanding that a bicycle is an opportunity to solve some market or customer problem, that’s great. We need to get there obviously. How do we validate that? Before doing anything, that’s a big part of what a PM does.

Once you’ve done or you have some level of validation, maybe it’s through a prototype or through some paper experiments, through some interviews, at some point, you're like, okay. We’re going to build a bicycle as our product, but that’s not where it ends. I think for a lot of people out there in the industry, a lot of product managers, it sometimes does end there. It’s like, okay, great. Team, build this bicycle and let me know when you’ve done it. I’ll take it for a ride and if I like it then I’m going to say cool, we’re done and we’re going to ship this thing. You could then spend months on just that great, we’re building a bicycle. How close are we? We’re about 80% done. Are we going to make this date? I think so. Maybe. There’s a lot of tension that happens because a lot of the interesting stuff happens in the detail.

You can imagine breaking down the bicycle into 30 or 40 individual stories that start with there’s a frame. We can see a frame. Okay, great. Now there are two wheels and you can roll the frame on the two wheels. You start introducing things like brakes and handlebars and the bell. Every one of those is an opportunity to ask, is this really necessary? Can we get some feedback on this more in isolation as a small piece rather than the whole thing? For me, that’s really enjoyable. I spend a lot of my time still in that sort of thing.

Suzanne: Taking things apart.

Dan: Picking things apart because you just find so much opportunity in that picking apart. It’s the conversation. You realize people are making different assumptions when you get into that little detail. One thing that has I guess evolved over the years in the agile community is this question of whether we should be estimating stories as we break them down with the team. That’s always a good topic for debate.

One of the things that has happened is some teams, some people out there have latched on to estimates as a terrible thing to do because managers misuse it and people start gaming it. Once you start putting numbers or any metrics around how long something might take in advance, we’ve always seen it a different way. For us, it’s always just been an opportunity to have a conversation around something. You’ve broken things down to small pieces. Now you can ask questions about each of the pieces. You can ask questions like, how complex is this?

Estimating as a team, in particular as a team is when the assumptions get uncovered because different people estimate something wildly different on the same team about one of these smaller chunks that you’ve decomposed, it means you're making an assumption that’s different from the assumption that someone also is making. Great. Let’s have a conversation about that. It turns out that you're making the wrong assumption or the other person is making the wrong assumption. Now we can actually clarify and get our assumptions on the same page so that we … Because obviously, the cost of discovering that now is much lower than it would be downstream once you’ve actually built something. It’s about the small pieces. It’s about the decomposition.

As a PM, you obviously don’t want to lost sight of why are we here? What is the big picture? Where are we going? What’s our vision? What are we doing this? For our customers, for what problem? Being a PM today from my perspective, it’s hard on multiple levels; (a) because you’re bringing all these different disciplines together to solve a problem, and because you're constantly having to switch modes and/or the levels that you're operating at. Are you thinking strategically? Yes, but 10 minutes from now, I have an iteration planning meeting where I have to … all the way down to the lowest level of granularity, and it’s such a huge distance between that and where you have to spend the morning on a typical day. It’s really interesting. I think that’s actually the real skill to hone over time, is being able to constantly switch perspectives and levels of where you're operating.

Suzanne: You're absolutely right. User stories is a unit of granularity. I use Tracker at the Development Factory. When I’m in Tracker and I’m writing stories or I’m writing acceptance criteria, I am in it. If I get pulled out for an afternoon or a day or frankly in my circumstance, usually a week or two and then I have to come back into it, it takes my brain a while to remember how to think at that level. This is a theme that comes up a lot on our shows. I think PMs do struggle because you can be really, really in one or the other, but being in both or being fluid enough to go between both, as you described, is for sure challenging.

I want to ask you in particular about acceptance criteria. One of the things you're describing is you're talking about a lot of really important things so I want to highlight them. Number one, in agile, we talk about individuals and interactions and this idea that coming together in a discussion can yield a lot of important insights and eliminate assumptions even between just two or three team members. Oh, you were thinking there was going to be a Facebook share button. I didn’t think it was going to be. Oh great, well, I’m glad we got on the same page about that. Do you advocate for product managers or product owners to own a significant amount of the writing of acceptance criteria as part of bringing it to get into the backlog or do you advocate for that to be co-created in individual sessions? How does that come alive best in your experience?

Dan: That’s a good question. This comes up a lot. In fact, we, I don’t want to say struggle with it. When I say we, I mean we the Tracker team which is 30-ish people, multiple staff teams working together, multiple PMs. We have a few exploratory testers. We have multiple designers. We have 20-something engineers. The we are my current experience or perspective is from that.

Going back to the question, acceptance criteria. This comes up a lot. It comes up in a lot of our retro. It’s stories that were not clear enough or maybe where it starts is stories are like a team or a project or some epic that we worked on. We had a pretty high rejection rate. We can track that because in the Tracker, you can look at metrics. Rejection rate means high cycle time, meaning the story was just going back and forth, back and forth, back and forth for a week or two weeks, which is really bad. We get into, well, why did that happen? Oh, because there were some lack of clarity on the story. The PM prioritized it. Maybe they’re working with one of our testers and the tester was more in the forefront of making sure it works because the PM happened to be busy in some planning meetings or whatever. They should have been right there as part of acceptance, but it happens when you have multiple people involved.

It goes back to, well, should we have more formal acceptance criteria on every story? Where it always ends up is, well, it depends. It depends on the PM. Where it also goes is, well, if you look at those stories that had lack of clarity, they’re pretty big stories it turns out. Yeah, they might have been estimated as a two or three so we didn’t really think it was a huge story, but it turned out there was some room for interpretation. It goes back to the question, well, what is a story? Should it be this formal requirement that captures every single detail right upfront? Well, sure. If you can make that always be true, if you know every single detail then great. Why not capture it maybe in the form of acceptance criteria? If you have that much to hold in your head or this, not much to capture then maybe that story is a little bit too big.

A lot of times, the answer is to break the stories down a little bit more. Each one is pretty simple. It accomplishes or the intent is singular. As a user, I can do blah because whatever. Great. One thing. Every story should have one thing that it brings to the table as far as moving the product forward. In that case, it turns out that acceptance criteria is pretty redundant. You can look at it and go like, yes, I understand the intent of this. I understand what we’re trying to do. Oh look, there’s a little mockup on the story. There’s a design. Do we need acceptance criteria? I guess. When you break things down to that ideal lots of small stories, I feel personally that acceptance criteria is nice but it almost shouldn’t be necessary. It should be clear from the story.

There’s also this mindset or this perspective that the stories are evolving conversations. If it’s going to be an evolving conversation, how can you possibly capture everything that is to be known and verified when it’s complete at the beginning? You can’t because it’s an evolving story.

I think again, it goes back to you're a small team. You should be having a ton of communication around everything. You have to stand up every morning. You're physically connected in some way, whether you're sitting right next to each other or you're on Slack and you can just track or mention each other all the time. If there’s any confusion around what it means to accept a story, great, let’s have a conversation about it. Also, by the way, it should be the same person that wrote the story accepting it. Do I need acceptance criteria for myself to verify what I’m going to do or to tell me what I’m going to do to verify the story when it’s done? No, because (a) I broke everything down. I have this mental model of where the stories are and what they represent. I have to make sure that the rest of the team has the same understanding.

To that end, maybe it’s not acceptance criteria. It’s just being super clear. Breaking it down so they’re small and then each one just be super clear and then be available if there are any questions. Just mention me on Slack and I’ll be literally in the middle of, I don't know, getting on the train or whatever, walking somewhere or driving and in one hand is my phone.

Suzanne: Hopefully at a red light then.

Dan: Of course, at a red light, driving at a red light, and I will just reply like, yeah, that’s it or, no, or we’ll just jump on or hang out or zoom. For me, actually, now that I realize this whole question of like-

Suzanne: You just solved it for Tracker right now.

Dan: Acceptance criteria is like the tip of an iceberg of lots of conversation around process.

Suzanne: I think you're going to issue a company-wide memo tomorrow and you say I had this epiphany. There’s no longer acceptance criteria. You know what got me thinking hearing you speak about it, and I think this is potentially an interesting inflection point because it also speaks to the Pivotal or the Tracker customer base. Part of that trust that you're referring to comes from working with the same team on the same product over time. Tracker is a number of years old. I’m sure people have come and gone. We know what it looks like more or less, except for when we’re introducing new elements. We know who our customers are more or less, except for when we’re going through a new phase in the adoption lifecycle.

Some of the details that you might typically introduce into acceptance criteria don’t need to be there because there is already a strong foundation of what the product is. Let’s look by contrast at a scenario like mine at a company like the Development Factory or even Pivotal Labs who as an outside consultancy is working with an outside client on maybe a new product or a product that isn’t going to be there for a long time and now there are these other unknown elements. What is this product? How should it look? New questions that need to be. Maybe it just speaks to, well you said, it depends. That’s the official product management answer. There is I think a different kind of challenge that third party product management teams have that changes when you're part of an in-house team for a specific product.

Dan: Yeah, I absolutely agree. I think the it-depends answer applies here as it does in every other part of this conversation. I do think there’s some emphasis on things that should or can happen outside of once you're at the point of writing stories and actually writing some code or building the product that can go a long way to create that maybe shared context and/or understanding. Whether it’s about who the customer is or about the nature of the product or what problems we’re trying to solve here. I think sometimes that can get a little bit overlooked or we rush to like, okay, we’ve got our … We know what we want to build. Here’s the stories. Let’s go write some code. It might lead to a lot of questions or a lot of that shared context that could have been established earlier on in some way.

I know a lot of Pivotal Labs’ projects still, I think all actually, start with this establishing of a common language and shared understanding and have some process around that. Whether it’s a consulting engagement with a new customer or something more in-house or evolution of existing product, it goes a long way. At labs, they call that process that they do, it’s called in inception. That could be a multi-day, sometimes a week-long experience of getting everyone who’s going to be involved in the project into literally the same room and immersing that entire team, that group of people into the problem space such that when you come out of it, you feel like there is a connection. You understand the goals of the project. You understand the personas that are relevant to the product or the project, the software that you're building.

It’s a lot of techniques for doing that these days. Building up personas and having them be very visible and shared with everyone. You really can connect to Suzanne, the product manager, and get yourself into this mindset that we are solving problems for her. We understand her.

Suzanne: Am I a persona at Tracker?

Dan: You know what?

Suzanne: I would like to be.

Dan: I think we’ll make sure you are. We’re going to put you in the log and say this is our number one. I think there are so many different ways. Whether it’s building persona as we’re doing these story mapping style inceptions where you're breaking the project down together as a team. You're not just doing that as one or two people ahead of that shared project experience and you bring in developers and designers later. You start with them. Sometimes it’s hard to do that in practice because getting everyone that will be involved on a project into the same room for multiple days, that can be a pretty expensive proposition because you can’t bill maybe for some of that time for some of them because your customer is not going to pay for all 12 people sitting in a room for a week just soaking it up. I think there’s just so much value there.

If I was that customer, I would certainly pay for all 12 people being in the room for a week because I would understand that shared understanding that comes out of that. It makes a huge difference I think downstream where you can then act like a more connected, gelled team and you don’t have to explain every little thing at every step of the way in the form of, for example, acceptance criteria down the road.

Suzanne: For sure, I’m glad you bring up personas or foundational documents. One of the ways that so many companies struggle is when you have to start onboarding new team members, if you don’t have places for globally shared understanding then everybody always has to be brought back to the beginning. An inception meeting, if it’s the kickoff of a project or an initial product idea and then foundational reference documents that are there, and maybe part of the answer is how much of this acceptance criteria is global and could be pushed to a more global understanding versus how much is unique to this story? There are other challenges that it raises. One is you brought up this idea of cost and maybe clients not wanting to pay. In this increasingly commoditized landscape, a lot of people approach product with a project mindset.

Meaning, I want to give you a fixed amount of money for a fixed amount of time and I want a fixed amount of output. When that mindset is there, everything else becomes a problem because how do you explain this idea of iteration? How do you explain this idea of continuous improvement? Those two things are in congress. I think even Tracker, it began as a project. It began as a solution to hand cramping and then it was adopted, but there is an adjustment between well, now we have this thing and, oh, we have to build on top of it and learn. Sometimes that means doing the work over. Can you speak to that a little bit, this project versus product mindset?

Dan: Yeah, absolutely. I think it would benefit all of us if we just banned the word project from most situations. I think here, it’s somewhat … The conversation here I think is a little bit about we are providing a service as a consultancy. Let’s say we’re in that situation. How do we approach these engagements with our customers? We could probably apply that to internal products within larger organizations too. There’s always some customer or some stakeholder and they have some expectations in mind. I think there’s too much imagining or thinking of these artifacts that we’re setting up to build or these problems we’re going to solve as these very finite projects.

The word project implies that there’s some finite aspect to it. Whether it’s a date by which we’re going to be done and the thing that we built is going to be complete, which these days, can you really say that about anything to do with software? Is any piece of software really ever complete? It’s complete in the sense that we may be stopped working on it or we stopped paying our consultancy or a team to do any more work on it. If we think of it as a product, what is a product?

Product is about solving some problem for somebody who’s willing to pay you money for it. There’s demand for it and there are customers. They have their problems. All of that will evolve. Your customers’ needs will evolve over time. You give them the first version of your product that you're building and they’re going to say, oh, that’s great. Now we’ll give you some feedback about that you haven’t solved that problem. Now you have to keep going because you have to actually solve their problem because you haven’t yet. They’ll say that’s great. You’ve solved my problem but now I have this other problem that we need to solve. You open the door and you keep opening doors. It’s not just problems. It’s also opportunities. You solve something in the market and that creates more opportunities for you so you have to keep going. If you don’t keep going, somebody else will and they will displace you, competition.

I think just having this mindset that what we are building is for the long haul and it’s more like we’re continuing to provide a service. That service has to keep aligning to where the needs are and so it has to just keep going. I think that mindset needs to apply to both the code that we’re writing. That code has to be malleable and sustainable, and people have to be able to come and go, and new developers have to be hired into it so they have to make sense of it. They have to keep it going. We’re not just building something and throwing it to the wall, then back to the product management aspect of it.

At Pivotal Labs, we struggled with this at the beginning because the natural tendency of most clients would have preferred or perhaps the norm was and may still be that having the … Basically, scoping the project to something finite and agreeing to what it’s going to deliver and when, so basically having it all. You can’t. You don’t want to be the hook to build something that has a bunch of unknown, there’s an unknown element to it. You're going to discover so much detail as you go. They want it fixed bid contracts where we agree to how much we’re going to charge them and we’re going to give them all of the things that they are asking for in some document.

As soon as you get into it, a week or two later, you realize most of what was in that document doesn’t make any sense because you’ve learned now. You’ve learned some things by actually starting to build and start to get feedback and it’s invalidated everything else that was in there, or it turns out that there’s a bunch of other stuff that wasn’t even considered as part of the document.

We made a point of never agreeing to fixed bid projects, and everything is about creating that trust on day one, that relationship, that mindset that, hey, we’re going to learn a lot here. We don't know where this is going to end up. I know you have this idea of this is the thing that you want to build and you're going to launch it on this date and this is what’s going to happen when you launch it. This is a hypothesis. Maybe we weren’t using the term hypothesis a lot back then because it got introduced later as part of the lean culture. Everything is just a hypothesis. We don't know anything. We just have these assumptions about what may happen. If you do this, if you build this feature then your customers are going to pay you more money or do something else. Maybe. Maybe you're completely wrong because you have no idea how people will behave until you actually put your product in front of them.

Let’s just get into a mindset that we are providing a service here. We’re going to join hands here and we’re going to start learning by building and shipping and getting feedback and looking at whatever KPIs, metrics or numbers that are important to us. Based on that, we’re going to make new decisions and we’re going to keep doing this. We’re going to keep doing this as long as you want us to keep doing this. You pay for our time. We are going to be fully transparent about what we’re working on, where we are. This is where Tracker comes in because once you get everything broken down into super fine grain detail and actual stories, it starts to make everything very concrete.

One of the reasons we have these things called the release markers in Tracker, basically the way it works is you range your stories in whatever order you think makes sense. Then, you put this little line, it’s a blue line at the point where that has some meaning to you. We want to do some kind of a demo here or we want to ship something here. Great. We’ve done that. We’ve broken everything down together. Now we have this shared trust because we’ve worked through the problem with you; you being the customer, I being the developer. We took the time. We spent a few days in a room. We broke everything down. We arranged it in the backlog. Some trust came out of just doing that because it shows that I understand what you are asking for. We talked it through. We broke it down. Great. Now we have our first backlog. We’re starting to move through it.

We realize something, or you as a customer realizes like, oh, but I also want it to be blue when I click on this button in the corner but not when it’s Tuesday. Okay, let’s think about that. That’s great. We’ll write a story for that. We’ll have a conversation about how complex that might be through the estimation. Now let’s drag that into the backlog. Oh look, it pushed that release marker down. Why did it go down? Because you just added more scope. Normally if that’s a conversation, it’s just a conversation, it ends up being this somewhat controversial or it has the potential to be confrontational, like, come on, I want you to do this one feature. I know it wasn’t in the spec but it was implied by the spec. Clearly, you just do it. Yeah, it’s going to cost us more money. It’s going to take longer. I don't know what you're talking about. You just do it.

You do it in Tracker. At least you make it very concrete by breaking it down. Together you drag that story in. You see the line moved down because you’ve added scope. It changes the conversation. They’re like, oh, you're right. I see that that will be a problem because we’ve just increased the scope so maybe we should take something else out. As soon as you get into the habit of working in some way, and it doesn’t have to be with Tracker, just make it as quantitative as possible, make a list of cards and say, okay, you just increased the size of this pile. There’s a trade-off between scope and time. We can focus on getting this done in a certain amount of time, but all we have to do is take a few cards out, drag a few stories down.

You start getting into the habit of doing this all the time every day with your customer. Again, more trust, more transparency around everything. It’s just this working relationship where we’re always having conversations like this and we’re constantly making decisions about how to stay on the right path. If making a date is really dear to us then we’ll just manage scope so that we can get to that date. If we don’t care about the date as much and we care about the most delightful product when we do launch them, let’s focus on having the right features, but we’re going to keep finding opportunities to have that conversation every day.

Suzanne: I love this idea of banning the project mindset. I think that it also perfectly complements something that you said earlier which is the importance … or that you’ve been saying all along frankly, which is this importance of decomposing or subtracting in something. The nice benefit is when you can get somebody to embrace the idea of let’s go from the bottom up, especially if dollars and cents are involved, say it’s actually to your benefit because if I can achieve the business objective or the user objective with one-third of the effort to deliver this feature, that’s money back in your pocket.

It almost never works out, having worked certainly with fixed cost projects for many years, it almost never works out in your favor to have to force a fixed cost from the outset as a client because well, then, the developer has to provision for every possible permutation and all of these things and say, look, trust is a big important part of it. You're right. Transparency that you're describing here. That’s one of the things that I think is so great about using whether it’s a tool like Tracker and there are others, there’s JIRA and there’s Trello and Mural and they all have their own different value proposition, but I think it brings transparency to the process. People get relieved when they can just see in. It’s no longer a black box. It’s, oh, here’s where we are. Here’s where we’re stuck. Here is where testing needs to happen. Suddenly everybody is part of that process together.

Dan: It’s true. I think it requires a certain commitment from everyone to be involved enough because sometimes, you're working with a customer that just doesn’t really have the time or the luxury of making this commitment to spend enough time with you to go through that decomposition and to operate and work with you at that level of detail that requires them to be involved more. In which case, it’d stop because they have limited time and so they can only operate in this form where they’ll capture the high level intent or this is the product that we want. Now here you go do it. In which case, that’s fine. We just have to embrace maybe a different kind of relationship there. They have to put somebody that they trust in the position of working with you and spending more time and being involved in that level of detail that’s required to operate the way that we think is more ideal.

Suzanne: Very cool stuff. Before we wrap up, I just want to take us through a segment we do on the show, it’s called Get the Job, Learn the Job, Love the Job. I’m looking to you. Our audience is looking to you for your wisdom. You’ve been doing this for a long time. You came up as a developer. You’ve played an integral part in building a company. You’ve been a product lead, product manager. How do you get a job as a product manager? How do you stand out in a stack of resumes? How do you convince somebody to give you a chance?

Dan: That’s a good question. I actually can answer that I guess from my current position of having to go through stacks of resume virtually and looking for ones that stand out. I’ll tell you what doesn’t stand out for me, some things that come to mind. Seeing resumes that are extremely dense and filled with every acronym and buzzword you can possibly fit on to it. I think those just immediately go somewhere other than where you would like them to go. I think it’s a combination of having a story that goes with your experience, and usually the cover letter is where there is a bit of a story. Seeing that somebody took the time to just show some clarity around why they’re interested in this particular position, why are they a product … What is interesting about product management? Tie that to something in our world.

These are just basic like you're looking for a job. Take the time to invest in something personal that actually connects your experience and what you bring to the table in terms of your skills with what the given company is looking for or something about them in terms of the culture. Pivotal is pretty well-known out there. You can Google it and quickly find, hey, what matters to us? We’re all about teams. We’re all about collaboration as teams. We’re really into pairing and test driving. We’re into products because we do a lot of products, but there’s just so much out there.

If you're applying for a job at Pivotal as an example, just do a little bit of homework and say, hey, I’m interested in Pivotal because I’m really excited by your relentless focus on small cross-functional teams and making those teams be really happy and productive. We’re also into a very sustainable way of working. Everybody goes home at 5:00 and we eat breakfast together. There’s a social aspect to it. Again, every company is different, but every company has some kind of a cultural differentiator to it or there’s something about it that makes it a little bit different or tries to be different. Find out.

What does it mean to be a product manager to you? If I’m talking to the person applying … because PM-ing is such a broad skillset these days. People come to it from all different angles. Some were a developer and then they found their way into product management or maybe they start at marketing or just business, maybe design. Actually we’re seeing a lot more of that now, designers moving into product management. I want to see a story. That’s what I’m interested in. Where did you come from and how did you become a PM and why? Because some people just stumble into it. Well, I became a PM because nobody was doing it. It seemed like there’s this stuff that had to be done that was about making prioritization decisions and getting everyone together.

Suzanne: That sounds like it was your story.

Dan: Maybe. I want the story. The story I think is important about how you got there because it’s always interesting. If there is no story, I almost wonder. You can’t just be a PM. You didn’t go to school and become a product manager. How did you become a PM? With the exception I think like General Assembly and maybe a few CS programs out there, product management is like this new industry or it’s a new profession that … I think one of the problems is that we’re using the same term as what something else used to be called. I feel like product management 10 years ago was something very different than what we’re talking about today. Product managers today, it’s a different kind of skillset. It’s a different focus. We work differently.

I want to know how you got there probably because I’m curious because I’m always interested in how people end up being product managers. Not just littering your resume with everything I’ve ever done and they include all kinds of unrelated jobs like marketing, marketing, marketing, product management. Just blow up the PM piece. Talk to me about how you build something. Having that as experience, you’ve actually brought something into existence. You’ve actually brought a product in and you made product decisions. You weren’t just a project manager that took on a product title because you're building a product, but at the end of the day, all you were doing day to day is project management. I think having a clear understanding of what product management versus project management is, is also very helpful because I think there’s some confusion out there as to what a product person actually does versus project.

Suzanne: I think if anybody out there is listening and is interested in getting a job with Dan and the team at Tracker, just write in your cover letter, number one, I think we should ban the word project from the vocabulary. You’d probably come right into a second interview at that point.

Dan: It will go to a different pile at least.

Suzanne: What about just blind spots or areas where either you yourself have failed in your career or learned lessons the hard way or where you see some of your PMs typically struggle?

Dan: I know I have a lot of learning the hard way with … Latching on to my idea of what needs to be built as far as a feature or which feature or how the feature should work, because you really get wrapped up in your own product. For us, it’s nice because we use our product on a daily basis. We built a product that we use all the time so we have that luxury. Maybe especially in cases like that, you get pretty passionate about what you think you should build for your product that your customers and users will also want or they’ll want it in the same form.

I’ve learned and so have others on my team and teams around us that you can’t. You have to build the passion. I think there’s a balancing act of having some vision, and this is what we struggle with because some people are more intuitive and have the sense of where the product should go and what it should and shouldn’t do. There’s those that are just very like, no, show me data. Let’s prove it.

I feel like I tend to be more on the former side. I just have a sense and I look for the validating pieces of info that reinforce where I think it should go. I think the ideal is somewhere in between because the opposite is also maybe not as ideal. We’ve learned because we built some big features over time that like, no, maybe didn’t quite get the results that we were looking for, or we went too far with it before we got the real validation of like, okay, it’s out there. Let’s watch the metrics. Oh, only 7% of our users are using this on a weekly or daily basis. It would have been good to know that early. I do think that you miss on something if you are just nothing but data-driven and completely objective because maybe sometimes you do have to go a little further to, I don't know, get some delight out there and get people excited and maybe solve problems in ways that might be a little bit interesting or unique.

I’ve always struggled with, what’s the right balance of that? How much of the intuition? How much of the vision do you bring to the table versus only data drive you and make decisions for you? I think it’s something that you have to experience, and I think we all have different personalities. I think it’s good to combine opposing perspectives where on our team, we have a PM that’s very skeptical and like show me the data or I don’t believe you. We have also the opposite. That’s also true on our design team. I think just having the right balance of these perspectives together is a good answer. For me, I will probably continue to relearn some of the same lessons, but I’m at least wiser to the consequences of when I do choose to go down more of an intuitive or fuzzier path rather than being super objective about it.

Suzanne: I say a lot that the better we get as product people, the more at risk we are for making the mistakes that we shouldn’t make as product people because we go straight to the solution or we … What you were talking about a little bit there, is falling in love with our own solutions or losing sight of the critical. What do you love about it? What keeps you in the game?

Dan: One thing that will always keep me in the game is the team aspect of it and being part of this gelled, tight-knit, almost like a family. You are in it together. You have this shared experience constantly. For us or for me, just seeing so many people out there use our product on a daily basis and like, yeah, it has its challenges and it could be doing things in a much better way than it does in some regards. We still get a lot of positive feedback. Every time there’s a piece of feedback like, hey, guys, I really enjoyed this new product. It really helps us with this and that. That’s just great. We feel like we’re making a difference to somebody out there. The fact that they’re using our product to build out a product is really rewarding.

It’s like this meta thing. Our success if there is the success of some other thing out there that was built using our product which is great. Just seeing things come to life. It’s frustrating sometimes because things take long, especially on a mature product or a project or it has a lot of things going on. Progress is measured in usually months. It’s hard to just like tada, we’re just going to add this new feature and, boom, it’s out there and people love it. It all has to work with what’s already there. There’s a lot of complexity here in code base in terms of other features. Just seeing things make it out there and getting that feedback and seeing my team visibly proud of something that they’ve done, that’s really rewarding for me too. All these things I think that come together.

Suzanne: That’s a cool insight. Tracker is in the DNA of every successful software product.

Dan: That’s a good line that we should put on our marketing site.

Suzanne: You can use that as a positioning statement.

Dan: I’ll tell our marketing team.

Suzanne: Great having you.

Dan: Thanks, Suzanne. This was fun. I look forward to more sessions like this in the future.