Switching From Waterfall To Duration & Price Contracts (With Tucker Sauer-Pivonka From Crema)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston: Welcome to the DPM Podcast, where we go beyond theory, to give advice that works, for leading better digital project. Thanks for tuning in, I’m Ben Aston, founder of the Digital Project Manager. Now, projects rarely go to plan, and when plans change, it often creates a whole lot of stress. Calls have to be made, meetings schedules, plans updated, estimates recalculate, and, usually, change requests issued. But, what if there was another way to manage change on your projects? In this podcast, we’re going to be lifting the lid, in a different way, to approach managing change with agile contracts. So, keep listening to understand how to get agile contracts to work for you, and understand the benefits and challenges of making this approach work.

Today, I’m joined by Tucker Sauer-Pivonka, he is the Director of Product Management at product managers, and really helping them grow and develop. And also, he’s in charge of, kind of, evolving their best practice, as well. Hello, Tucker.

Tucker Sauer-Pivonka: Hello Ben, nice to hear from you today.

Ben Aston: Yeah, you too. So, one of the things I just wanted to ask you, actually, as we start; I know part of your role is development of the team, and I wonder if you can, kind of, share some of your insights on what you’ve found that’s really worked in helping your team develop and evolve. Maybe around the contracting that you’re working with or experimenting with. But, how do you nurture the team and help them grow? What have you found that works for you?

Tucker Sauer-Pivonka: Yeah. I think the one thing that you have to recognize early on, is that everybody learns a little bit differently, everybody needs a little bit different ways of coaching. So, one of the first things I do with my team members, is I sit down with them, and I start to evaluate that. How do they learn? How do they like to receive feedback? How do they like to receive praise? And I keep track of all that, so that way I can tailor my approach to something they’ll all respond to, a little bit better. I think it… I spend a lot of time in our one on ones, individually. Going through different topics with them, and different areas for growth. I mean, really coaching them for anything that they’re having issues with, at the moment. I mean, they’re just going to come up as they come up, and then we take it on. On top of that, we have a book study going on, at Crema right now, around a book called Multipliers.

So, that’s a big aspect of growth for our team. And then also, of course, conferences. So, we have a conference coming up, I think, at the end of September, that we’ll be going to. That’s also in and around product management. And so, we’ll be going to that as a team, not only to just… For some team building, but also to learn about some new topics.

Ben Aston: Nice, so what’s the name of that conference, do you know?

Tucker Sauer-Pivonka: Industry: The Product Conference, is what it’s called, it’s in Cincinnati, If I remember correctly.

Ben Aston: Party in Cincinnati, if you want to join Tucker and the team. But, I just want to dig into… You mentioned you’d… with the team, you’ll, maybe, cover all different topics. I’m just curious as to, maybe, if you could share any of the topics or areas that you’re helping the team get through? And, what are the challenges that the team are facing, that you’re helping them overcome?

Tucker Sauer-Pivonka: Yeah, I think it looks a little bit different, again, for every individual, just because we have different skill levels for different people on our team. So, it does look a little bit different. But, some of those things have really been around… A lot of it that we do in the group setting, is around client management. So, “my client said this, or my client is requesting that we do this thing, but we haven’t really talked about that. So, how should I handle this?” And so, I’m being generic, because I can’t think, off the top of my head, the perfect example to give right now. But, it’s something like that.

Client management things are typically the trickiest things to teach somebody how to do, so it’s a little bit more of a discussion on, “I felt weird about this, I don’t know that, that was the right way to handle it. Was that right? Or should I handle this in a different way next time?” And that’s usually the directions our conversations take.

Ben Aston: Yeah, it’s so true. I think if… there’s soft skills around Client Management, and Team Management, as well, isn’t it? But, there’s never a single right answer to… Right? It always depends. But, I think we can always grow and improve in those areas. And, you mentioned going to a conference, as a team, which I think is awesome. But, I’m curious to understand a bit more about where you go for inspiration, and how you keep up to date with everything that’s going on. How do you stay current, and how do you get inspired?

Tucker Sauer-Pivonka: Yeah, I stay inspired by, kind of, using a lot of different things. One of those are books that I read. I read a lot of articles, so… Really, Medium is somewhere I go, quite a bit for inspiration around product management, specifically, or managing teams and what that should look like, or could look like. I think, what I have to remind myself, is that Medium is a great resource, but sometimes you need to take things with a grain of salt, because anybody could post an article in there. And so, just because they can post something on the internet, doesn’t make them an expert, buy it certainly, if you’re just going with that attitude, it can at least give you some context, in how to handle certain situations.

So, I use that quite a bit, and then, those are, really, the main two. But then, I also will, just more industry-wide type things. I really like Wired, the magazine. So, I usually read most of the articles in every issue. And that just helps me keep up to speed on different trends that are happening outside of the PM world its self, but more into what’s happening with technology, overall.

Ben Aston: Yeah, awesome. And, what’s the… In terms of technology, are you a… someone who, kind of, stays in the bleeding edge of tech? What’s the latest toy you’ve bought?

Tucker Sauer-Pivonka: That’s a great question. I wish I had something super exciting to tell you. But, I would hate to say, that I’m on the bleeding edge of it, because I would consider myself an early adopter, but I’m not, … really, any earlier than that. Right? I usually try to get new products, when they come out if I can. I’m, kind of, salivating over a new iPad right now. I have an iPad Pro, which is fine, but I want the new version, and I just can’t justify it. Because my work’s, I mean, that’s the great thing about Apple products now, is it works fine, I really don’t reed to replace it. So I can’t really justify it.

But I have been, most recently, the latest version, I’m showing my Apple nerd, here. But, the latest version of iOS, and iPADOS, and everything that came out of WWDC was super interesting to me. So, I have been thinking a lot about that, and thinking about what the impacts that those things will have on the industry, as a whole. Maybe, even on some of the products that I’m creating. And so, that’s been the biggest one, recently, that I’ve been looking at. And then, on top of that, I’m a little bit of a Zelda nerd, and the latest… The birth of the Wild sequel just got announced, and so I’m geeking out over that, too.

Ben Aston: Nice. I am… My thing that I’m looking at, at the moment, is the DGI Rover. I don’t know if called a Rover, or what it is, but they announce that the little camera thing on a little tank, that you build yourself, it looks awesome. That’s on my shopping list, as my next thing to buy.

Tucker Sauer-Pivonka: That sounds like fun.

Ben Aston: Yeah. Again, it’s one of those things, isn’t it? Do I really need this? I don’t really need this? But, it’ll be good for the children, they’ll enjoy it. Of course, I’m curious that you, when you mentioned, that you love your iPad Pro. In terms of that, your hardware or software, is there anything else that you’ve found, recently, that is making your life awesome, that everyone should know about?

Tucker Sauer-Pivonka: You know, I have struggled over the years, on trying to find a balance of taking hand-written notes, taking typed notes, tracking tasks, all of that. I’ve tried to find a balance, so that way… Because there’s a lot of information out there that says when you write something down, you comprehend it a little bit differently than type something, and that’s intriguing to me. And so, I’ve always been trying to find what that balance looks like. For a while, I was taking notes on my iPad, using the Apple pencil. That got me pretty far down the road. But most recently, the thing that I’ve shifted to is… It’s, kind of, in the middle ground.

So, I sit with my iPad, or… my computer to… I was, kind of, like the final repository for everything, for work. But, what I’ve been doing recently, is I’ve been also carrying around a little notebook with me, where I do take my day to day notes in, I do track, I put tasks in, as they come up, that kind of thing, all in my physical notebook. And then, at the end of the day, I will transfer those things into an app called Todoist, to track all my different to-dos. As well as, the in-state is that I put my notes into there, and process them at the end of the day.

Now, that in-state, I’m gently getting into that right now. But that’s been, really, the latest thing, the biggest shift in my workflow, and it’s been really helpful. It’s just, I notice, and I’m comprehending what I’m doing a little bit better. And then, it’s allowing me to track my tasks a little bit better, so I’m not immediately jumping into them. So, even from a time management perspective, I think it’s been really helpful.

Ben Aston: Interesting, so you’re using a physical notebook, I mean, that’s to take notes. That’s where you’ve gone back to analog, for note taking and reminders, and things like that. Is that, kind of, how it works?

Tucker Sauer-Pivonka: Yeah. But then, it eventually gets put into a digital space. Because I think, for me, what ends up happening, is nothing can replace opening a notebook, clicking your pen, and just starting to write. I think my biggest struggle with using the iPAd to take notes with an Apple pencil, and this sounds so silly, that there’s time involved with opening up the right app, finding the right notebook that you want to use, making use that you’re Apple pencil charged. There’s all these things that seem really small, but really, end up being barriers, to just being able to write a note.

So, what I noticed I was doing, is I was carrying around my iPad, and a million sticky notes, because, … writing on sticky notes, if I have an issue. If I just need to start doing something, and I was like, “This is not sustainable.And, it’s, kind of, silly to just carry around all of these sticky notes.” So that’s, really, what caused me to move to a notebook.

Ben Aston: Interesting. It’s a battle that I deal with, as well. My latest approach is, I’m using Evernote. And I have one notebook, which is my to do list, and another one, which I just call a scratch pad, and it’s just a dumping ground. So where, if I get really anal about making my notes… I want my to do list to look nice, and to be ordered, and I was always messing it up.

So, I’ve now introduced this scratchpad, which is “Hey, all the raw stuff goes in there”, and then it gets transferred into my to do list. Which, it sounds like a bit of a similar system. And then, I have a tiny notepad that doesn’t allow me… it’s deliberately really, really small, so that I can’t write. I can write reminders, but I can’t write notes on it, it’s too small. So, that tried and force me into using my system. Otherwise, I’d start creating different list, in different places, and it ends up a big mess.

But, yeah. To do lists, there we go. But, let’s talk about the article, and this was a case study that you wrote for us, which is really interesting, and it’s about switching fro waterfall-style contracts to duration and price contracts. And, we’ve talked about agile contracts before, and actually, in the DPM school, we had someone ask this week, “Hey, give me an example of an agile contract”, and I sent him the link. Alexa wrote a great post on agile contracts, before. But for those who are unfamiliar with agile contracts, can you, just briefly explain, what is a duration and price contract and how does it work?

Tucker Sauer-Pivonka: Yeah. I’ll explain how it works, from the context of, obviously, how we do it here, at Crema. That doesn’t mean that has to match this exact formula, but that’s at least, what I’m most familiar with. So, what we consider a duration and price contract is, really centering a project around a dedicated team. So that might look like, two full-time developers, a half-time test engineer, a quarter or half-time designer, and then, maybe a product manager. Well, yes, a product manager, and maybe a strategist. Both at quarter-time, each.

And so, it’s, really, more focused around the team its self, and the goals that you’re trying to drive towards, rather than listing out exact deliverables and features, for example, with exact hour estimates right next to it. Because, what we have found, and I think, why we see a lot of success with this, is that software is too complicated to try to estimate all of it upfront, and assume that everything’s going to go exactly according to plan. It would be a great world, if we could just plan, and everything just happened exactly how we intend it to. But, frankly, that never happens.

And so, we find that, what these contracts allow us and our clients to do, is to really shift to wherever the highest-priority work is at. So that way, at the end of the duration, and even along the way, throughout iterative cycles, we’re delivering whatever the highest values is to the business. Because, in a fix-go contract, those could change over time. Let’s say, it’s a six month contract, and then you get to the end of your contract, and you deliver features that are no longer relevant to the business. So, this really allows us to shift wherever we need to, in order to match the client’s needs.

Ben Aston: Cool. So, I mean, you’ve talked about the kind of projects that make sense for agile contracts, and software development. Product development, being a great case in point, where you want to be able to have that flexibility to pivot throughout the project. But, I’m wondering if there’s anything that you’ve come across, in the process of trying to adopt these kinds of contracts, any types of project where you tried doing this but that agile duration and price contract didn’t work so well?

Tucker Sauer-Pivonka: Yeah, I think there’s a couple instances, maybe not so much for us, but maybe for others trying to evaluate what makes sense for the, because you need to evaluate the type of work that your doing. So, like you said Ben, the reason this works for us, is because we’re developing these products that are really hard to detail every single thing out, and have some kind of calculated risk along with it. It’s really hard to do that, and often times, ends yup in going over or either that’s the supplier: us, or the client paying for it. And so, you really have to evaluate what type of project you’re doing.

Now, if it’s something that’s repeatable, let’s say you create these standard websites with this many pages, with this type of layout, that kind of thing that you do over and over again. And it’s a very repeatable process, you can have that calculated risk and do something that’s more fix-go. We don’t do that type of work, but I think that’s something I could see, where more of a fix-go makes a little bit more sense. It’s, really, more about predictability and unpredictability, and everything that you’re doing.

Ben Aston: Yeah. Because I think, another dialogue that is emerging, I think. Well yeah, people have been talking about it for a while, but it’s the idea of value-based pricing. And this is, obviously a very different to value-based pricing. Value-based pricing, when you say, it’s for a more predictable kind of project, that way you’re able to say “Hey, well… Hey Mr. Client, the value of this work that we’re going to produce for you, is 50k”, And so, you charge 50k for it. Now, the idea is, that you spend less than 50k producing it, but you sell the value, rather than selling hours.

So, I’m wondering if you can explore how that kind of value based pricing, that people are excited about, how that fits with this very straight forward, honest duration and price kind of contracts, where you get the hours that you pay for. How has that impacted overall profitability? Have you found that actually, well, things are a lot simpler, you’re able to be more profitable, because it’s very predictable, because there’s a built-in margin on everyone’s hours? Or have you found that, even just by that you’ve encountered sticky situations, where you’ve had to eat the cost, and a value-based pricing, where you’re like “Hey”, in the example of the case study that you present, “Hey, originally you estimated somewhere between half a million and a million, what if you’d have just charged a million? And then you could have then tried delivering it, for less than a million.”

Tucker Sauer-Pivonka: Yeah. I think that’s a great question. I think, inherently, I think it’s two different things. Right? So, when we’re building software, and we’re doing a duration-price model, part of it is that we don’t necessarily know what the very end result is going to be. So, because that’s not predictable, it would be hard to put a price tag on it, at the beginning, because you don’t know what that in-state might look like. Because, it could change, because the client might change their mind, that kind of thing. I think value based pricing works really well in scenarios where you can say “We’re going to”, like you said “We’re going deliver this thing, that’s going to deliver this value to your business.” Maybe it’s a design sprint, or something like that. That, I think, is a little bit easier to manage, but when your building a big product, that’s a little bit harder to do.

When it comes to profitability, on duration and price, I think that’s one of the beauties of it, is that it’s, kind of, all built-in to the way that you do it. Because, they only have an allocation of a team, and then that allocation, I mean, that really is, in its self what they’re getting. You’re delivering… So, let’s say you have two full-time developers on it. Well, you’re not really like quote/unquote going over hours, because you’re not really looking at it like that. You’re looking at what allocation of that person that they’re getting, and you’re delivering that value sprint, over sprint, over sprint. So it’s not quite, you don’t really have to worry about profitability, because you can’t really under deliver in that scenario. You can’t really be under hours, or over hours because it just doesn’t… We don’t… It’s not set up to track that way. They’re not paying hour by hour.

Ben Aston: Yeah. So, they’re buying a team for a duration of time? Have you ever come up against the scenario where, at the end of the sprint, or after a few sprints, the client turns around and says, “Hey, you’ve been working on this for three sprints, and I don’t really think we’ve go the value.” Like, “You made a mistake”, or “You did something wrong”. Like, we all make mistakes, and particularly when we’re working with development, things don’t go to plan. So, how do you deal with that kind of scenario? When the client doesn’t feel that they got value for the time?

Tucker Sauer-Pivonka: Yeah, I’ll say that doesn’t really come up too frequently, and one of the reasons why, is that we work really diligently to have alignment with our clients. Not just on each sprint kick-off, but throughout those sprints, and keep them in the loop on anything that’s changing along the way. So I think… Honestly, I think one of the ways you manage that the best, is a lot of good communication and client management.

So, like I said earlier in this podcast, I think that’s one of the reasons that our product management team talk about it so much, because it’s what leads to being able to humbly say “Hey, we thought this thing was going to take us two sprints, it looks like it’s going to actually take us three or four because of what we found out. And here’s what we found out. Here’s why we think it’s going to take this long. Now… We can back up, and we can just move on to something else, if you want.” But, really lying all the facts out there for the client helps make those decisions, and helps take the emotional aspect out of those decisions, a little bit more.

So, I think that’s probably one way that we do it the best. And then, again, through every single sprint that we have, even before we took off, we’re lining with the client, on what we’re including in that sprint. We’re making sure that the team feels comfortable about delivering what we’re talking about, in that sprint. And then, at the end of it, we’re demoing whatever we got, and if there happens to be carryover, or we found out something else, then we just chat through it, and chat through why that is, and make sure that the client clearly understands. So that way, they don’t come back later and be like, “Wait a second, this is not what we thought it was going to be.”

Ben Aston: Yeah. Cool. So, I want to dive into the case study a bit, and talk about the timeline. In the case study, you talk about, you said you knew it was going to be, at least, seven months of work. And, I’m wondering how you got to that estimate, if you weren’t entirely sure what you’re building. A seven month timeline, that’s not an insignificant project, or product development. So, I’m wondering how you got to that initial seven month estimate. Was that before you had done the prototyping phase, or what that afterwards?

Tucker Sauer-Pivonka: Yeah, that’s a great question. So, in that particular instance, it was, and in most of our projects, that’s after we’ve done some sort of prototyping or testing type of engagement. So, that’s usually a little shorter, six week engagement, in this case, is also included a technical audit of their existing system. And so, how that helped inform the time frame that we’d thought we’d be in, in order to deliver on the goals that they were trying to meet. So, when you’re trying to estimate things, it’s a little bit of something that comes with experience, and as you would do more and more projects, you start to get a good feel for what takes a certain amount of time, what the complexity is.

But then, there’s an aspect of this, that includes the actual production team. So, in that case, we wrapped up the prototyping and testing engagement, then as a production team, we sat down and we said “Okay, we can’t really sit down here, and define every single story that we’ll do, because that won’t be helpful. Again, because things will change.

But, can we take a look at what our goals are, and what the different pieces of this pie look like, and how complex each one on of those and, kind of, give them some rough T-Shirt sizes. And then from there, we start to come up with a recommendation on team size. So, seam makeup. How many developers, what allocations a test engineer need to be, that kind of thing. And that’s all based on the complexity of what we’re building.

And then, on top of that, the duration is not so much about… Again, because it’s not a deliverable focused agreement. Right? So, what it’s focused on, is those business goals, and it says, “Okay, we know that thee is work here”, and in this case, we knew there was a fair amount of work that would last seven months. But we felt like, within those seven months, the team could stay really focused, and be able to deliver on all of those goals. And, it was more about what does the client. What are they looking for? What is their appetite for budget? Because frankly, software’s never done. You’re never done working on software, there’s always new things that come up.

And so, we knew that there was enough there, that we could at least get seven months, is what they would need as a minimum in order to build what they need, now that we knew that they might need something beyond that. But, to essentially get them what they were asking for, that’s how we arrived at it. But really, it was around focusing on the business goals, what the client was… What the client budget appetite was, and the coming at it from software’s never done, but we think we can deliver these things, in this time frame, and we’ll work with you every sprint, to make sure that we’re working on whatever’s the highest priority.

Ben Aston: Yeah. I’m guessing, part of that assessment was, when you originally won the work, was ascertaining whether the client… Could they only afford seven months? Or, could they… With software, the reality is going to be, that was always going to go beyond seven months. So, I guess, part of is ascertaining whether or not that client has got that appetite and that budget to carry on beyond that.

Tucker Sauer-Pivonka: Right. And I think, let’s say, for example, that the client wanted only a three month contract. Perfect, that’s totally fine. We’ll do it, let’s do a three month contract. And then, we’ll just make sure, within those three months, again, that we’re working on the highest priority, working at this. At the end of the three months, we will get the highest priority work done.

And so, it’s more about… It’s really thinking of it as you’re quote/unquote renting a team. You’re going to get whatever that team can produce in those three months, six months, a year, two years. Whatever the timeframe is that you feel like you would like, we’ll work around that. And then, again, since we’re just focusing on wherever the priority is, then it’s just a conversation around that.

Ben Aston: Yeah. And so, you talked about, the first thing is prototyping and validation engagement. Is that a… Was that a fixed price? Like, you mention six weeks, I think. So, did you just base that, then, on three two-week sprints, and you said, “Okay, this is the prototyping and validation engagement.” And I’m wondering, how well defined those deliverables were at the end of those six weeks?

Tucker Sauer-Pivonka: Yeah. So, technically, it still falls under our duration and price model. But, I would say that it is probably a little bit more fixed price, in terms of, if you were to compare that contract versus our regular contract. They do come with certain kinds of deliverables. Right? We do say, in this kind of engagement, we will deliver you, a high-fidelity prototype, we will deliver the sketch files, we will deliver all the user interviews, and the notes, and the corresponding research.

So, some of those things, we do put in there. Things that we know we’re going to be delivering on. But it, technically, is still duration-based, and if things shift within there, so let’s say, for example, we get three weeks in, and we realize that whatever we’re talking about is not what users want. And so, we need to go back to the drawing board, then we can do that. Not based on “You have to get this exact things, it needs this many screens.” That kind of thing. It’s just, it’s still duration and price based.

Ben Aston: Which is good, because I think, often where things fall down is, even in the prototyping phase, where you develop a prototype and the client’s like “Hey, well… Do you know what? I don’t think that’s quite right.” And that’s before you’ve even tested it with users, they start wanting to tweak it and change it. And you’re like “Okay, well, you know we didn’t really account for that. We were just trying to do a quick process up, and get some quick feedback.” So it works, if it’s duration and price based with that, as well.

So, after the six weeks, you produce this prototype. You do some user testing, you get some feedback, and then you’ve produced this… You’re saying “Hey, it’s about seven months work.” I’m wondering if you did kind of, like bottom up or top down, with that half million to a million figure. Did you base that on asking the client, “Hey how much money have you got?” And work, back from that? Or, were you… Because, like you said, software’s never done. So, I’m wondering how you evaluated or calculated the client’s appetite for the size and scope of the product development?

Tucker Sauer-Pivonka: Yeah. So, luckily, in this instance, where we ended up, was that we came up with rough, like I mentioned earlier, like rough t-shirt sizing of what we were trying to do. Roughly, what the complexity looked like, kind of, have an idea of a technical plan. And so, since we had all of those things, we were able to built out what a road map might look like. Now, we were very clear that this road map could change, and would change over time. But, that was the way that we were able to get to the original seven months.

Now, we didn’t necessarily know what their appetite was, when we presented that proposal. So, we put together a proposal, we talked through what we’ve done so far, we talked through where we’re going next, and what that potential roadmap would look like. And then, roughly, what we would be including in each thing, or what we though would be the highest priority, again, subject to change based on what they think.

And we started with that, and then having the technical team there, having, obviously, myself there in the room, and having our strategist there really helped define what those seven months would look like. We were like, “Okay, this section of the application is going to, roughly, take a month and a half. We know that.” And so, we put all these things together in a roadmap, and then that’s where we ended up getting to that. That seven month number.

Ben Aston: Cool.

Tucker Sauer-Pivonka: Now, in that proposal phase, when we are presenting to them, after then, we just make just sure that they know, “Hey, if this doesn’t work for you, we can adjust this. We can go back to the drawing board, we can talk, we can start having conversations with you about what you think you would need within three months, for example. If that’s somewhere you want to start, let’s start.” Or, having issues about that. But we were close enough with the client, at that point, that we had… We know that they were feeling like what they wanted in the quote/unquote MVP, and so we were able to build a roadmap to fit that. And that’s how we ultimately got to the seven months.

Ben Aston: Nice. So, I want to touch on methodology, next. And you, kind of, described, in that case, that you’ve been approached being agile stroke scrum. So, I’m curious, what do you take, from the Scrum bible, which is, obviously, very prescriptive, and what do you leave behind? How do you see your approach being different from the text book Scrum approach. I’m particularly curious, around the product owner role, and whether or not that’s the client, or someone on your team, whether or not you have Scrum masters. The roles that you’ve been talking about, you didn’t mention a Scrum master or a product owner. You talked about a product strategist. So, how does your approach differ from the internal team that scrum really prescribes and build it self around?

Tucker Sauer-Pivonka: Yeah. I think a common thing that you’ll hear around here, is that we put people over process. And so, I probably stole this from somewhere, and I wish I could attribute it to somebody, because I don’t remember who. But it, we really practice Scrum with a lowercase s. So, what I mean by that, is that we make sure that there’s enough flexibility in our process that people aren’t restricted by it. And that if a team needs to adjust the process to work better with their client, they have the full autonomy to do so.. That’s really the high level approach we take with it. And then, in terms of the roles, and how it differs a little bit.

So, in agency structure, it’s a little harder to do that type of thing, where you have dedicated roles for everything. When you’re an actual software company, let’s say that you’re Apple. That can look a little bit different because of the way that you’re funded, the way that your business runs, that kind of thing. So, in an agency structure it doesn’t always work that way. So, what we do is… So, you mentioned the product owner role. So, typically, who the product owner is, is our day to day client contact. They’re usually considered the product owner.

Now, if we have a strategist on the project, sometimes they will be a, kind of, like a co-product owner, in coaching that person. Because for some of our clients, they don’t know what it means to own software, they don’t know what it means to build software all the time. And so, the strategist will, kind of, be that co owner with them, and help them make decisions on the overall strategy, the overall direction of the product. Really, those product owner responsibilities.

Now, sometimes that can fall to our product managers, if we are in a different type of scenario, I won’t get too much into that, but basically, sometime we’ll have products where the product owner is on the client-side, but they might not be able to be in day to day contact with us, as much. So, the product manager might act more, in that regard, into some product owner responsibilities. But, obviously, reporting those to the client.

On the product manager side, we bundle the product manager and the Scrum Master into one role. Which I know, goes so against the grain, when you talk about traditional by the book Scrum methodology. We just found that it works for us. It hasn’t broke yet. I mean, when it does break, we will adjust. But for now, it’s worked just fine and we run all the ceremonies, and we run, most of our stand-ups are automated, but we set those automated stand-ups up, we check them every day, we make sure that we remove the blockers. Those are all just things that fall under our responsibilities. And frankly, it’s kind of nice, because we have all the context we need to make some of the more product management type decisions.

And so, I would say that those are probably the two areas we depart the most from. Scrum with a capital S. But the rest is pretty much the same. We do our sprint planning, estimating, retrospectives, product demos. All like you would expect us to do. We just bundle them into one meeting, usually, called a Wednesday Kick-Off. But that’s… Yeah. For the most part, it’s pretty similar.

Ben Aston: Yeah. So, with this kind of… I mean, you’ve talked about, sometimes the client is a product owner, sometimes it’s the product manager on your team. And I want to touch on managing change. In the case study, you talked about they’re conflicting priority. That they wanted to make this new thing, but the old thing, where you had to keep the lights on, became more and more broken, as they kind of… Payment processing, I think it was, that stopped working, or was about to stop working.

So, often in this scenario, you’ll have the client who’s… They want both, they want to have, “You need to keep building the new thing, and you have to fix this old this, as well”, and the scope’s increasing. So, I’m wondering how you manage those conflicts in priorities, and how you educated the client through that, to manage that backlog. In Scrum, we’ve got a backlog of things, and it’s the product owner’s role to groom the backlog, to make sure things in the backlog, in their priority order, that they should be.

But, what once one project became two projects, essentially. I’m wondering, from a high-level perspective, how you educated the client through that? And then practically, in terms of actual backlog, whether that was, endure Trello, or whatever it was, how you helped the client with the communication of that, what’s going on in that backlog management.

Tucker Sauer-Pivonka: Yeah, so I think the very first part, the very first thing that you need to tell yourself, or that you need to think through is that when it comes to priority shifting, you need to be really, especially in an agency environment, you really need to be empathetic to what’s causing those changes in priority. Most of the time, the client doesn’t even want to shift priorities, they want you to stay focused, because they want you to deliver what they originally were asking for. But you need to come at it from an empathetic standpoint, and understand that they would not be asking you to do this, or asking you to change things if they didn’t absolutely need to.

And that’s the first place to start is, understanding what is the cause of the change? Is this truly a high priority? Is this a squeaky wheel type of situation? Is this something that a stakeholder said, that you’re doing to make sure you appease the stakeholders? And to be clear, all those are very fair answers, it’s just understanding where they’re coming from, will help you form how you communicate to them. So, that’s the first place to start.

And then, the second place is making sure that when you are communicating, that it is abundantly clear, and I mean abundantly, that by shifting things, it changes the plan entirely. So, let’s say that you’re working on a product, you’re working on this huge new feature set, you’re really… The team’s all behind it, you’re about halfway through with it, you’re making some good progress. And then, this hot new feature thing comes in, that they need right away because a client of theirs just signed on, and that contract is worth a bunch of money, and they need this feature.

So, that’s a very common scenario. But, the product team needs to get behind that. So, on our side, that’s… So, after I understand that, then I go to the team, and I say, “Hey, the reason that they’re asking about this, is because of the situation.” And then it takes the emotion out of it, a little bit more, and the frustration away, because then it helps the whole team understand why we’re doing what we’re doing.

So, that’s where I start, and then after we all get aligned, I just, again, I make sure, at checkpoint along the way, that the client understands by doing this, the team is moving off of this other thing. When we move off of this other thing, it means that we’re not going to complete this other thing by when we thought we were going to complete it. Which is fine, to be perfectly clear. But, it does change the plan a little bit. And so, I just make sure that it’s ultra clear what decision that we’re making.

And in this case, in the case study that I wrote, we didn’t really, we thought we knew where the end of that work was going to be, but we didn’t. And, it took a lot of communication with the client, along the way, to say, “Hey, this is fine, but just so you know, it’s really taking us away from the larger business goal that we were trying to reach.” And that was okay, and that’s, again, okay with us too, as long as they’re aligned with what that means. Because it can become an expensive mistake, if it’s not the right thing to do.

And then, I think, on the tool front, any kind of visualizations that you can use. Even within the tools, whether that’s Jira, or whatever you might use. Those could be really helpful to communicate what that looks like, because sometimes a client, and I learned this lesson, also, on this project, or it was a good reminder, at least, was that I would say some things, but sometimes it doesn’t always… You can say one thing, but it might not register the same way, if they see it visualized.

Ben Aston: So, do you give them access to Jira, then? OR, do they use Jira? Are they in Jira?

Tucker Sauer-Pivonka: Yeah. We take an approach with our clients, of full transparency into everything that we do, so they have access to the tools that we’re in, we have them as guests in our slack team. But yeah, they get into Jira. They actually get into there to help make sure, do we have the right priority, do we have the right requirements here, is this the right direction we want to be going in? So, we have them in there, quite a bit, to make sure they’re aligned with what we’re doing. And like what we were talking about earlier, that helps when you get to the end of the sprint and they’re like, “Wait a second, I thought this sprint was going to include that?” And then, it doesn’t happen as frequently, as they’re seeing what you’re putting into the sprint now. So that’s to it.

Ben Aston: Yeah. And, you talked in the case study, about getting to a position of trust. And that transparency, obviously helps that. You talk about, as well, in your lessons learned, about the importance of delivering these artifacts, and you talk about updating the roadmap, updating the burned-down chart. But, what for you, in that whole… You know, there’s so many different things that we need to communicate, how do you keep that, or prevent the client from being totally overwhelmed? Because if you don’t have a particularly technical client, and you put them in to Jira, and you’re showing them all these different things. The back log `you’re showing them the work in progress, they’ve got access to everything. How do you maintain that position of trust, and make sure that they don’t feel like something was swept under the carpet, because it was a comment in a ticket somewhere, and they didn’t see it?

Tucker Sauer-Pivonka: Yeah. That’s a great question. And I think part of that answer derives from being, like admitting humble mistakes, being humble about the mistakes that you make. So, I think that, if you do that frequently with a client, it can build a lot of trust, really quickly, because then they understand you’re not BS-ing them because they’re like “Oh, well they just told us that they made this really embarrassing mistake, but they told us how they’re going to fix it.” And so, it help build that right away. The more and more that you do that, the more they realize that you’re the real deal. That you really are trying to build their trust, that you really do have the same interest in mind. Like, their success, is our success, they’re referrals are our success. We want to do good work, on both fronts, and so, just being really upfront with all of that.

From an overwhelming standpoint, I’m getting into the tools, we don’t require that clients get in there` we just make sure that they have it if they want it. And then, what we do with our clients, is we’ll create personalized screen capture videos, walking you through a tool, like “This is how you use it. Here’s how you find what you’re looking for. Here are some helpful tips, here’s some area that you probably don’t need to worry about.” And then, we just make sure that if they are feeling overwhelmed, that we have an open door policy, that they let us know, so that we can remediate it rather quickly.

And truly, we haven’t run into too many problems with that, there’s been a couple of instances, where there’s been that overwhelming feeling, but it’s more so around checking to make sure all the designs are right, and that kind of thing, because especially, on these big products, you can have 500 screens and then the client can all of a sudden, get overwhelmed, because they’re like “Oh my Gosh. I have so many screens to review.”

And so, one way to get around that is just making sure that when they have access to the tool, so they can go in there as needed. And two, that we try to deliver things to them, very iteratively, and trickle them, so that it doesn’t all just end up in their lap at one time. That doesn’t always work, because sometimes pile up overtime, and we try to tell them that it’s happening, but if we try to be upfront like that, it tends to help quite a bit.

Ben Aston: Cool. And one of the things that I wanted to ask you, is in terms of the level of reporting, you provide. So, obviously the client’s paying for a team, for an amount of time. Do you provide a kind of reporting on time spent, and time sheets, and things like that? Or do you just say to them “Hey you’re buying the team, and you just trust us, that we worked on the project.” How does that work?

Tucker Sauer-Pivonka: Yeah. So, really, what the reporting is, at least with something like you’re talking about, is making sure that we’re delivering results. Right? So, we have metrics that we meet, every sprint. So, for example: at the end of a sprint, we will go through what was completed in a sprint, what, maybe wasn’t completed, we’ll talk about what our velocity is, maybe it went up, maybe it went down a little bit. We’ll talk about why that might be.

And so, we really focus on the results that we’re delivering them., because that speaks to allocations. We don’t report on ours, again, so they’re not… It’s not… Yes, they’re buying a team, but we’re not saying “Oh, this is the exact amount of hours it’s going to take for this feature.” And so on, so forth. So we’d don’t provide that level of reporting for our clients. But, what we do use that reporting for, is to make sure that our allocations are correct.

So, if we have somebody who’s half-time on a project, are they spending over half-time on it? If so, we probably need to go back to the client, and let them know that we need to talk about either removing some of things from that persons plate, or raising their allocation. Or it might mean that, maybe, it’s a slow season, and maybe they’re a little bit under. And so then we’ll talk about, taking that allocation down. But traditionally, that does not happen, it’s very rare for that to happen, usually the allocations are pretty spot on.

Now, there aren’t any variants from week to week, that kind of thing, where maybe I’m quarter-time on a project, and one week I ended up putting in half-time, because there were some big things going on, and I needed to handle some things, and I had a trip, or whatever it might be. The next week, that balances back out, so we try to keep an eye on those, just to make sure that our allocations are correct. But, we don’t report those types of things, we just report on what work has been completed, what work hasn’t been. And truly, we’ve never run into issues, around that.

Ben Aston: Well, look at you. So, I want to close just by asking, when and how do these duration and price contracts not work? Has it ever all spectacularly fallen apart for you, ever? And what I’m… The situation I’m imaging, is when, and I mentioned this before, is when sometimes when clients are underwhelmed by the progress. But how, if someone’s thinking about taking this on, what should they watch out for, in terms of things going awry?

Tucker Sauer-Pivonka: Yeah, Things can definitely go awry, and especially around… Maybe the client is underwhelmed by the progress, and I think, what I would encourage those people to do, is just to make sure that when they start to get hints of that, which as long as you’re communicating frequently, they should start to feel some of that. It’s going to feel like there’s a little bit of weirdness, or something going unsaid. And, to honestly, just come from a rally frank spot and be like “Hey, I don’t feel like we’re on the same page about something. Can we talk about it?” And really, just dive into the deep-end and figure out what’s causing them to feel overwhelmed, and try to start talking during that early. Because when you try to wait until the end, it’s not going to end well, because they won’t renew, you won’t have a chance rebuild that trust. So, when you’re starting to have that little bit of feeling of weirdness, your intuition is probably correct, and you probably need to have a conversation.

I think, in terms of, I don’t think I’ve ever had anything really fall apart, I did have a scenario, where we were getting ready to renew, and like you said, they were underwhelmed on progress, but then I talked to them about it, and understood where they were coming from, again, coming from a point of empathy. And we said “Okay, that totally makes sense, I totally get where you’re coming from. Let me go back, and let me take a look at some of the work that we’ve done, so I get to the bottom of what might be the issue, here.”

Well, what was the issue, was that we had moved on to some other work, based on priority change, and what they were expecting us to be done… What was expected to be done, by the end of that, before we moved onto our renewal, it got us off truck, by about two months, because we went two months, and worked on this other thing. Which is what they needed, for their business. But, that’s okay. But, me explaining that to them, they were like, “Oh, okay. Yeah. I understand.” Rather than the ones that didn’t. And they also, I didn’t point it out or anything, but remembered, after me talking to you a little bit, that we talked about what the impacts of those things are, what this could cause down the road, and then they understood how we work, a little bit better.

And then, each time those conversations happen, they build on top of each other. Because there can be this little point of frustration, you’re like “Okay, that’s fine. Remember that we can change this, at any point in time. We can move back to these goals. But, you’re really in the driver’s seat, here. So, just let us know where we should be moving towards, and we’ll make sure that it happens.” And that really helps us get back on track, really quickly.

So, I haven’t seen anything, so far, happen where it’s just completely fell apart. Really, most of it’s just around misalignment, and if the client’s not willing to get aligned with you, then that’s like, “All right, well maybe we just aren’t the best for each other. And that’s okay. Maybe that’s not what you want, and we can help you find a new partner.” But, that can happen some times. We try to find all that out, early in our sales process, so that we don’t experience that, further down the road.

Ben Aston: Yeah and I think, for me, one of the big learning moments, hearing your story is, it takes the right client, for this to work. So, I don’t think, what we’ve been talking about takes a certain maturity from the client, to be able to understand that things take time, that priorities, if priorities change, then that affects the timeline, and that affects the cost. And these are all things that, often, are very tricky, with clients because they have a fine-eye budget, they have a deadline. And, if you’re pitching against another agency, or another team, then yeah, everyone’s trying to be as competitive as possible, put their best foot forward. But that, often, doesn’t create the right conditions for managing client’s expectations, about what you can realistically deliver, for a certain price, or within a certain time.

So, a big part of this, from my understanding, anyway, is that new business process and educating the clients through that. Educating the clients through the prototyping and validation phase, and managing and setting their expectations, about what the engagement could look like. But then, the result of that is delivering value, right the way through, as is prioritized by the client. So, at the end of the day, I think the client gets a much better output, rather than the agency taking shortcuts or making prioritizing decisions that, perhaps, they shouldn’t be, just to try to get things on budget, or deliver on time.

So, I think the duration and price contracts is definitely an interesting concept to talk about. SO, thanks tucker, so much, for joining us today.

Tucker Sauer-Pivonka: Of course. This has been a great conversation. Thanks for having me.

Ben Aston: So, I wonder what you think. I wonder if you’ve tried an agile contract. I’d love to know how it went. Tell us what you think. Comment on this post, and head to TheDigitalProjectManager.com to join our Slack team, and you’ll find all kinds of interesting conversations going on, about all things project delivery. We’ve got an agile channel, it’d be great to discuss this, in there.

And, if you like what you’ve heard today, please subscribe, and take a couple of minutes to leave an honest review, for the DPM podcast, on Apple Podcasts. Ratings and reviews are really helpful us, and it’s greatly appreciated. But, until next time, thanks for listening.