A case study like no other. In this series of sessions at BoS Conference USA 2023 we deep dived into how Autobooks retooled their business and ask the question, “What Happens if Product, Sales & Marketing Work Together?”
By focussing everything they did on the needs of their customers and helping them grow, they also grew faster, made their lives easier and changed the way they think about collaboration across the company.
More on the Autobooks case study sessions.
Part One
Chris explained how his background working with Bob Moesta and Jobs to be Done alongside his experience using the Shape Up methodology were instrumental in his drive to get Autobooks focused on delivering the outcomes customer wanted. How did Chris, who didn’t have FinTech experience or the language of the industry even start? You’ll hear the steps he took over his first 45 days to interview partners, customers and execs to build a JTBD timeline, identified the four forces and applied what he learned to improving small business user adoption. What were the results? How did he get other people to buy into the process? What were the hiccups on the journey from launching a customer a month to launching 1500 a years later?
Chris and Justin describes the lightbulb moment with Derik and Kyle picking up on the success of this approach to SMBs, proposed that they applied the same concepts and the timeline to the banking space. If the timeline works for a small business owner, why doesn’t it work for somebody making the decision to buy Autobooks at a bank?
Part Two | Q&A
Slides
Find out more about BoS
Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.
Transcript
Chris Spiek
Hi everybody. I’m Chris Spiek. The last time I was on stage at Business of Software was exactly 10 years ago, and it’s great to be back, and it’s so cool to see. It’s like being among friends, truly it is. It’s great to see so many of the same people having been in touch with the same people for so long, and getting an opportunity to come back and hang out again is just great. The last time I was here, I did a live jobs to be done interview on stage with this gentleman, Tyler Rooney, about why he purchased a car, unscripted. Bob and I sat him down from hundreds of people and peeled back that story using the method that you heard Bob talk about yesterday. If you’re a seasoned jobs to be done person, you’ve probably watched that video, digested it, learned some interview techniques from it. If you’re new to jobs to be done, and you just heard Bob speak yesterday, it’s a great thing to go find Google Business of Software jobs to be done. You’re going to find that video. It’s going to be an amazing tool for you as you get into it.
And also, Bob, you look incredible. We left this and did a project with ozempic right afterwards. I’m not sure what happened, but absolutely incredible transformation. You look great, brother.
So I started my career as a software developer. I love to code. I’m not particularly good at it, so I bring people like Justin into the mix. Justin’s our VP of engineering who was really, really good at it, but started my career as software developer, did it for a number of years. Ended up having the wonderful opportunity of co-founding the rewired group with Bob back in 2006 2007 and spent a decade of my career popularizing and formalizing the jobs to be done framework.
So when we founded this, this was back when it was a footnote in Clay’s Innovators Dilemma, and a couple companies had used it. We didn’t have definitions, we didn’t have language, and we spent about a decade really sort of making it teachable and making it so product teams could use it and adopt it. And Bob had a great logo slide up there yesterday. This is a product conference, so I just picked the coolest ones. Spent some time at Facebook, spent some time at intercom. You heard that story, and then with the guys at Basecamp and lots and lots of other other software companies. It turns out I can tell stories about chewing gum, about Toilet Bowl Cleaner. This is like the exciting stuff, because we’re at a we’re at a software company so, or a software conference. So I listed these, and then after that, life stages happened. So met my wife. Our first son was born, and it was time to come off the road, stop consulting, stop traveling all the time, get a real, real job and actually scratch an itch around building. I love building things. I’m a product person at heart. And as fun as it was building the framework, I wanted to get my hands back into it and ship some code and build some product.
So I joined a company called Auth0. The engineers in the room will know this. Everybody else will but it was an identity platform at the time. It got acquired by Okta, a couple years later, joined them, when it was about 100 people, and stood up the product team there, and after a couple of years, joined this company, Autobooks, and Chief Product Officer at Autobooks today.
Justin Dickow
I’m Justin Dickow. I’m a VP of Engineering at autobooks. It’s amazing to be here. I don’t normally do this, so actually nervous, but so my basically background little bit less interesting so far. I’ve basically spent my entire career as a well, let’s see, as an engineer in a product role, or maybe as a product manager in an engineering role. I’m not actually sure. The point is, I’ve basically spent my entire career in product and engineering.
I met Chris and Bob in 2017. My mentor at the time, Ilya Stern. Shout out to Ilya, you should be here. Basically wanted to introduce me to jobs, so I went to it was called a switch workshop, I think, down in Detroit, and I did the same thing. So I saw Bob and Chris interview a woman with a seemingly inconsequential purchase, I think she bought like a Pottery Barn bookshelf, and it turned into this like incredible story with like emotions all over the place. I think people at one point in the audience were like blowing their nose, like people are sobbing for some, some reason. But the point being that it kind of introduced me to a framework that I was able to bring into not just on the product side. But basically at the time in 2017, Ilya and I were building a product development team. So same thing, product and engineering, and it gave us a framework to really be introspective about the progress that we needed to make within our own organization to ship the things that we were finding out during our jobs to be done interviews.
So we have been, had been basically using that framework for a few years. We built up the team, probably from maybe three to a couple dozen people and were fairly successful. My original talk basically said that I got really lucky and hooked up with Chris a few years ago, but I know that’s not right now because of Bob. So about seven or eight very specific things pushed me to start looking for something else. Chris and I connected, and when we started talking, we basically learned that the problems that we were having within the product and engineering organizations were not unique. We had exactly the same problems, and they essentially all amounted to we needed to change the way that we were working and innovate the way that we’re working constantly in order to keep up with the way that our business was changing. So I joined auto books two and a half years ago, basically at that at that point, this presentation is about that story, kind of starting from where auto books was when I started, to where we’re going at this point. And of course, we still have all the same problems, but just in different versions of it.
And I’m hoping what we can leave you with today is basically not, well, we could probably write another book on this, but not the whole framework, but just a few things that we’ve done. If you if some of these stories resonate with you, basically some a couple practical things that you can do within your your own organization to help change those.
Chris Spiek
Awesome so we’ll start with a just a little brief history of Autobooks.
Autobooks
So at its core, Autobooks is a platform for small businesses that allows them to send an invoice, accept payment, credit card, ACH payments directly into their internet or directly into their business checking account, and then do lightweight bookkeeping. Most of the businesses owners that you meet are not terribly excited about tax time. They’re not terribly excited about applying for a loan, right? They want to go run the business. They don’t want to do all that stuff. We automate a lot of it, and we take care of the thing that is most critical, which is, which is getting paid. The interesting thing about Autobooks is the way we go to the most interesting thing, I guess, is the way we go to market. So instead of just logging into Autobooks.co, which is our domain, if you’re a small business owner and you want to access Autobooks, you log into Internet Banking. Wherever you bank at, you’ll see your internet banking dashboard, which you’re all familiar with. You’ve got your list of transactions, and you can push money in and out and transfer and things like that. And you can also access Autobooks. You can look at your books. You can send an invoice. You can accept the payment, and it’s all integrated into internet banking, so it gives us tremendous distribution.
We’re seven years in. We’re in about 1500 banks, all domestic, across across the US, a number of top 15 banks. We’ve penetrated that, that up market space. And like I said, we’ve been at it for seven years. So we’ve got, we’ve got some momentum.
The interesting thing is, as you guys all know, we hit a series of road bumps along the way, and from a product and engineering standpoint, basically had to completely reinvent ourselves another a number of times to sort of get ourselves unstuck. We’re going to tell two stories today, hopefully that resonate and that help you guys. I didn’t know that we were going to be telling him in front of, like, the best storytellers in the world after that last presentation. So we’re going to run to Chris and Jamie, right when we’re done, and say, Tell us how to make this better, and where did we miss the mark. But hopefully, hopefully we land this.
So I joined Autobooks after about two years of the company running. We, at the time, they had done what most startups do, they bundle a bunch of features together, right? So I came into the business. We had, like I said, lightweight bookkeeping. We had Bill Pay, we had an invoicing system. You could accept credit card, you could accept Ach, you could get general ledger balance sheets, like all sorts of, I call it the Chinese food menu of features, right? You want the thing, and here’s the bundle, and you get everything.
And at the time, I had known the founder for a long time, and he approached me and said, you know, let me just talk through some stuff. And he basically said, I’ve got the bank sales side of this thing, I think, figured out down a path, right? So I’ve signed up a number of banks. They’re interested in the product. And the story on that side is basically, banks traditionally are very, very good at addressing up market commercial accounts, right? I take you out to lunch. You own a big business, I lend to you. I make a lot of money off of you, and I can service your account. And they’re also very, very good at just what they call retail checking accounts. All the personal checking accounts that you and I have where we deposit our paycheck and and go about it. The middle is really, really hard for banks.
So the small business, 1 million to 15 million, really not big enough for me to make a lot of money on a loan. There’s way too many of them for for me to wine and dine every month. And I got to figure out how to, how to service them. And, you know, they’re obviously members of the community, and there’s a market there, and I need to figure out how to, how to help them. So Autobooks, from a bank’s perspective, filled a really, really good niche there. When the founder approached me, he basically said, I got that figured out. I need help cracking the nut on the small business owner. I haven’t quite figured out how to get them to stop using whatever they’re using and switch over to Autobooks.
So you know my history, you probably know the playbook that I ran right when I sort of landed 90 days in. I had my feet on the ground, I had my hands around the data. I kind of understood what the company offered, and I was off to do interviews. So lock the product team and a bunch of cross functional people in a room 10 back to back interviews to arrive at the jobs that small business owners hire Autobooks to do, and this is the technique, right? We saw the timeline yesterday. We worked the timeline. What was the first thought that you had in running your business, that you needed something new, right? Because you’re making the things you’re selling, the things you’re building the website. Why in the world, all of a sudden were you thinking about accounting, thinking about sending an invoice, thinking about any of this stuff. And we did the interviews over and over.
Doing JTBD Interviews
And one of the interesting interviews that came out was this gentleman named Harry. Harry was an attorney. He did a lot of corporate work, so we had a bunch of corporate clients, and I get him to tell the story. And he said, I’ve got mostly big businesses. They’ve got an accounts payable department. I do the work for them. I send them an invoice. They cut me a check. This has like been doing this for years. Harry was in his 50s or 60s. He had a very established law practice, he said, but something happened. I’ve been doing some things for people around town, smaller deals. And somebody, a couple months ago now, asked me if they could pay me by credit card. And he was like, it was weird. It wasn’t a big deal. I said, No, I said, No, I don’t do that, and you can write me a check. But I put the idea in my mind.
And then I talked to one of my lawyer buddies, and he talked about, he does like the smaller stuff, right? He’s doing personal injury and whatever smaller cases. And he uses Square. Put that idea in my mind. Square didn’t seem like a fit. He also mentioned PayPal. PayPal is like, P to P like, I’m an attorney, I’m a professional. I don’t like see that fitting into my business, but he planted the seed. All right, tell me the rest of the story. And then two or three times over the course of two weeks, people started asking me, Can I pay with credit card? Can I pay with credit card? And finally it dawned on me, Okay, I gotta figure this out. Like, you know, I want to give people the service that they want, so I’ve got to figure out this thing. Who said I had noticed a couple of weeks but of weeks prior that in my bank they offer Autobooks, and it described it as a way to send an invoice and get paid. So I signed up. Looked at square but it’s like this. I don’t need another thing, another account that I’m putting money into. I’ve got my bank, and if my bank can help me out, I’m going to put it in.
So up to this point, this is, you know, interesting to us. The even more interesting part, two things came out of it was right at the moment where he talked about buying. He said, You know, I’ve told you this whole story, and we’ve been on the phone for 45 minutes, but I’m not like your everybody says this. You can ask, Bob, I’m not like your typical customer, like, I’m just like weird edge case. Okay, tell me more, Harry. So he proceeds to go through this process of saying, I don’t actually use your invoicing capability the way you think your customers use it. I feel like my clients deserve really detailed, elaborate invoices. They’re paying me a tremendous amount of money for really good legal services. So when I invoice them, I open a Word document. And he’s a writer by training, right? This is all he does write. Open a Word document, and I give them a very, very detailed description of what I did for them and why they owe me all of this money. And then I take that, I put an email, I send it to them, I create one line invoices that say, see a test Word document, and I send it out of Autobooks. And if they want to pay by credit card, they can pay me. And it’s working great. I’m getting payments by credit card. You’re doing what you say. What you say. But I tried the auto books thing, and you give me, like, a couple 100 characters, and it’s probably good for the painter and the lawn care guy and everything, but for me, it just doesn’t, doesn’t fit.
So this is back to Bob’s struggling moment. He’s adopted the solution, but he’s also innovating. There’s room for opportunity here, right? So we went on and we did more and more interviews, and we found two things. One was that there were plenty of people like Harry, and it fragmented in all kinds of different directions. We weren’t a perfect fit for his invoicing needs. He needed complex people needed complex attachments. They need DocuSign to agree to something. They need all sorts of different things that we would eventually solve, but we couldn’t solve now.
The other thing that we noticed was, as companies, people would describe themselves as an invoicing company or a company that doesn’t send an invoice. It’s like the negative space or the negative set. And the way to describe it is like, it’s the guy that shows up to paint the outside of your house. It’s going to be eight grand. When I’m done, you’re going to pay me. Pay me eight grand if you want an invoice that says materials and how much the paint cost and how many hours and like, I’m not your guy. I’m gonna do a great job for you, but you just get me the eight grand. I’m not gonna send you something, something cute.
JTBD research results
So what we came out of, out of this with, was an idea, basically two things. One, we disintegrated the product. So previously we had accounting, invoicing, bill pay, everything, sort of all bundled up with an accounting. Back to April. April’s talk an accounting first narrative. We did interviews, and we found out that business owners think about accounting twice a year. Once around tax time, and if they need a loan that year or credit, they think about their accounting and their books, but they think about getting paid every single day. So we pulled the product apart. We basically said, if you need accounting as an upsell, you can pay us a monthly SaaS fee. You can upgrade to it. But the real thing that we’re going to talk to you about in your internet banking system every time you log in is, do you need to get paid, or do you need to send an invoice? And those are strong calls to action. So one thing that came came out of the out of the job.
The other thing that came out of the out of the the jobs to be done research was what Harry had illuminated for us, was that we basically had an opportunity to pull the front end off of our invoicing solution and provide just a simple payment link that any one of our small businesses could send via an email, via text, via QR code to say I’m the painter. You owe me eight grand. I’m not going to invoice you. Click this thing, and you can type in your credit card number and your payment details, and we can complete the transaction and get down the road.
So for me, this is the dream. I’m 90 days in. I’ve got my interviews, I’ve got really crystal clear insights of what I want to go build. The tip that Bob didn’t give you yesterday, that I will give you is if you’re practicing jobs to be done interviews – small business owners are incredible, huge enterprises very difficult. 100 different people in committees, making decisions, that sort of thing. Consumers, I’ve done it on packs of gum. That was like an actual thing. It’s very fleeting. You can do it, but the small business owner, they spend real money on things, they can tell you the story. And at this point, I felt like, this is, this is fantastic. I’ve got great insights, and I’ve got, I’ve got a path in front of me.
In addition to that, we had an amazing team. So this team has been in the payment space for years and years and years. Payments are very complicated. In my mind, felt simple. You just move the money into the bank account and then you get into well, what happens if there’s a service that fails? Do you roll the transaction back? What if you miss the money or lose the money? It’s a, it’s a it’s extremely complicated. We had a very competent team of engineers ready to basically build whatever we put in front of them, and we were ready to go.
So the product team got together, we wrote up a really nice specification for what we wanted this product link, I’m sorry, payment link, payment form to look like and how we wanted it to operate. We kicked off the project. We were there with the engineering team. We were answering questions, we were guiding them along the way, and we were off to the races. And then something weird happened.
We shipped the wireframe
At the end of the project, we had budgeted estimated four weeks took six, seven, something like that. No big deal at the time, first project, but we ended up basically shipping the wireframe throughout the specification process we had sketched out based on a napkin. Here are the fields. The spirit of it, we had a lot of customer interviews that we could use for demand. Sketch the thing out, hand it to the engineering team. Again, answered whatever questions that they had. We were there the whole time. But what came out was the exact layout from the from the wire frame. Some weird requirements around fields. Email was required, description was required, things that like we had sort of worked through, and it was just kind of strange how it, how it, how it came out.
So we were pointed in the right direction. We had a good insight, but we just didn’t quite hit the mark. And I realized at the time, we’re going to have lots of insights. This is the first round of job speed on interviews. This thing is going to be flowing. And if I’m going to continue pushing work into the engineering team this way, I don’t want to miss the mark by 15 to 20 degrees every time like we need to be as close to hitting the bulls eye as we as we possibly can. And then, like Justin said, we started talking to people and having conversations. And it turns out that this is just it, a common place. A lot of people are struggling with this same sort of thing of having a confident insight and not not quite, not quite getting, getting all the way there.
So I went to work, and I had to try to figure out how this happened. The first thing I did was I picked up my my phone and I called Ryan Singer, how many know Ryan? Does the name ring a bell? Couple people know Ryan. So 37 signals are base camp. The project management tool was founded by Jason Fried, DHH (David Heinemeier Hansson), and the third guy was Ryan Singer. He did all the product strategy at Basecamp. We’ve been friends for 15 years. I worked with them on early projects there, and he had, they, they have just radical views on how to ship product, how to build product, how to organize teams. So picked up the phone, basically said, Ryan, I got this thing. I’m not sure how it ended up this way. You know, how do you guys do this? And what do you think that I should, I should dig into? He had all sorts of very specific, detailed questions about how we took the work and the specification and gave it to the engineering team, and what they did next. And they were all questions that I had no answers to.
I said we, you know, we kind of hoisted over the wall. We have all the detail that we can. We got the engineers in the room. They looked at it, they read it. So, yeah, this all makes sense. We answered as many questions as we could, but they were basically off to the races. And Ryan said, Yeah, but, but what did what did they write first? And how did they organize themselves in terms of what they would bite into and divide the work and how it would come together, and all these things. And I said, I don’t even know where to start or what you’re talking about. I’ll call you back basically.
So I went in to do the investigation, right? I talked to the project manager, I talked to the lead engineer on the team, and I basically said, tell me this story. I just want to make sure that we’re, we’re doing this the best way possible. And the thing that they described to me, which I would then the week later on the next project witness firsthand, was this notion of taking the written specification and almost literally slicing each sentence that the product manager had written up into a separate task for an engineer. And there was, it was basically called the kickoff meeting. You take it, you would divide up the entire project, hand it out, and people would start working. And at first glance, this is not a bad thing to do, right? Everything is tracked, everything is accounted for, everything is assigned to somebody. So this project is going to be off to the races and sort of down down the path.
The bad thing that we came to discover was that engineers, we all know, as we’re building things, are making tiny trade offs with every decision that we make, with every line of code that we that we write, all throughout the day. And as you take the whole of the project and split it into tiny, tiny pieces, those trade offs are lost. And so when we get back to the payment link or payment form and we say, why is email and the description field of what you’re paying for required fields, there were no answers. Somebody would say, well, those things existed in the model. So somebody got assigned the API to extend the API, and they’re required in the model. So we made them required, and then the front end guy, somebody completely different, was in charge of validation. They’re required at that level. I got to make them required here. But there was no conversation about what is the context that the user is in when they’re using this, both the SMB and the payer, and what’s the outcome that we’re trying to achieve, and how do we optimize this outcome? Because everybody was faithfully executing their tasks and not looking at at the broader picture.
So anytime I sort of pushed in and poked holes, and this wasn’t, you know, obviously this is all in the spirit of learning, so there’s no, there’s no blame here. But just, can we talk about how this decision was made, right? And there was really nothing. I got assigned a ticket, I wrote the code, passed the test, shipped it into production. As we went on, and we went on and we started observing this in more and more companies, product teams, engineering teams, we ended up coining the term the paper shredder, which is what this visual is.
You take the idea, you take the insight of where you’re going to go, you feed it into this process, and then out the bottom comes all of the tickets, and they all get assigned to people, and then down the path you go.
So we had to try something new. We basically got one team, called Ryan back. Hey Ryan, here’s the thing, what do I go? What do I go do? We took one team, we said, we’re going to try an entirely different way, different way of working, and we’re going to do an experiment to see if we can get closer to hitting that mark with the next project. And if we’re not going to do the paper shredder, what are we going to do? The first thing that we did was start with an entirely different attitude towards estimates. Previously we had start. We started with this is the exact amount of technical work that needs to get done, and this is the amount of time that it’s going to take, which is always wrong. We never get estimates right, but we still go through the ceremony right? It’s the thing that engineers hate the most. It’s the thing that product managers hate asking the engineers, because they know they’ve got to gross it up two times anyway, but we do this ceremony.
Estimates to Appetite
What we did instead was start taking a strategic look at appetites. We looked at each project and basically said, What is this worth to the business if we’re able to execute some version of this and ship some version of it? And then we sized the project that way. And people struggle with this a lot the two more recent examples that I have are just so you can kind of feel it for yourself, is we recently shipped an improvement to the way our nonprofit organizations use our payment link to accept donations. So we’re a small business, obviously serving company. A certain percentage of our small business organizations are non profits, and they collect donations. And we had a little we got some feedback, we had a little improvement that we wanted to make, that we knew we increase revenue. It was only for a certain segment of our users. It was still important to us. We went and shipped it conversely.
Over the past couple weeks, we have completely re imagined and redeveloped the way that we manage financial transaction payments through our system in a way that allows us to catch more fraud and allows legitimate payments to land in the SMB small business owners checking account at a faster rate and decline fewer payments, which we launched a couple weeks ago and has accounted for millions of additional dollars of transactions flowing through our system. We make money on interchange. This is a very, very good thing for us. You can already feel from the sense of an appetite, which one of those would get a lot of time and which one of those would get a little time, right? I care deeply about our non profit users, but it’s a small segment of our customer base, and when push comes to shove. Team, you got a couple weeks to get this over the finish line. If you need a month and a half to redo the payment system to get millions and millions of dollars through, you’ve got, you’ve got the time to do it. So we look at it strategically, and we basically allow for for that amount of amount of time.
Once you change from estimates to appetite. It basically gives you a completely different relationship with scopes. So what we went from was fixed time, variable scope, I’m sorry, fixed scope, variable time, where we say again, this is the body of work that we need to do, and it’s going to take as long as it takes, because our estimates are all wrong. So you need to get this exact thing done, and you basically got all the time in the world. We’re going to push you, and we’re going to tell you to work weekends, and we’re going to do all the terrible things to you. But in the reality, as long as it takes is what it takes. Did this new notion of fixed time, variable scope. So now we have an appetite. We’ve got an outcome that we’re excited about, whether it’s the nonprofit or whether it’s the way we handle payments, and we’re going to the team basically saying, this is the amount of time that it’s worth investing for this project. This is the outcome, and it’s up to you to figure out how to get it done.
Stop Assigning Individual Tasks to Engineers
And then the last thing, when you get those two pieces in place, the thing that it enables you to do is stop assigning individual tasks to engineers. In the previous way of working, we were shredding everything using the paper shredder, right? We knew the least amount about the project that we were doing. We would take the insight, we would shred it into into tasks, and then we had to bet that the recipe that we had come up with of all those tasks would come together at this magical moment at the 11th hour when we were shipping the project at the end, and manifest itself into what we were imagining at the beginning. And we decided that that was not the right thing to do. Instead, we moved to assigning projects to teams. So the change that we made was basically moved the project manager. These are not easy things to do. These are human beings. There’s other projects to manage. But we took the project manager, moved them off the team, completely, took the scope that we were writing, put it in front of the engineers, the senior engineer, and the people that were working on the work and basically said, this is the objective. This is the amount of time that we have to invest in this that we feel good about. It is up to you to figure out how to divide this work up, figure out the best way to approach it, work through all the trade offs. Obviously, product management is involved, and we’re representing the customer, so we’re along the journey with you, but it’s on you to figure out the best solution in terms of of how to get this, get this done.
And it really, if you’re kind of connecting some of these talks in your mind, it should resonate with Bob’s visual yesterday of the person standing on one side of the river trying to get to the other side of the river. I’m mixing metaphors here a little bit, but you heard, you heard Bob talk about, The more I understand about the user. I can build a bridge. I can build a tunnel. Give them a life preserver. If I want to build that, I can teach them to swim. I can build a robot. These projects all have the same spirit to it. You get a good group of technical people in the room, and they can imagine lots and lots of ways to get it done within the appetite that you’re allotted. And now they’re at the level of the code, making really, really good trade offs, not just staring at one ticket and one card and getting that task done and and moving on to the to the new task.
The best thing that came out of this, in my opinion, one of the best things was that we ended up with focused, autonomous teams. We give these people projects, we give them an amount of time that they need to get it done. The caveat to that is, you can’t do that and then go interrupt them 1000 times. That’s torture, right? So you give them the work, you leave them alone. This isn’t gospel. Things come up. The last thing they shipped had a bug. They got to go in and fix it. But for the most part, there are no meetings. We don’t do stand ups. These teams don’t have overhead that. They need to be in all kinds of all kinds all kinds of meetings. They’re able to go head down, do good working sessions with each other, and get through the work, get through the work that they need to get through.
This story is from end of 2019 into 2020, so again, kept working with Ryan, tweeting, talking about it, things like that. More and more and more people kind of coming up saying, Yeah, this is this is resonating. It led to Ryan publishing a book called Shape Up, a couple years ago, with which has all of these practices in the book as long with case studies. If you pick the pick up a copy of the book, it’s actually free online, you’ll read the story of the payment form in pretty detailed explanation of how we went through, wrote a better pitch, avoided the paper shredder, and kind of got through the, got through the the entire process.
Oh, Bob and I had a challenge. Who would come up with a name? And yeah, I got to, I got to name those. Thanks, Bob. But that’s not what we’re here for. We want people who are struggling with this to make progress.
Justin Dickow
You named the book?
Chris Spiek
Yeah.
Justin Dickow
I didn’t know that.
Chris Spiek
Well, now you know.
So first story, my hope is you’re not hitting the mark. You’ve got great engineers. You’re scratching your head. How do I figure this out? You’re able to go through and use, shape up and get it working. The great part of the story is that, what is this? We’re in the hero’s journey now. This is forever, ever after the new way. So we shipped consistently for the next couple of years. We added more teams. So this was a one team experiment. It worked. We folded the rest of our teams in. They started jamming. Obviously, we have product managers that provide a consistent flow of insights. So we’re always interviewing, couple interviews a week, and then we do projects. So we’ve got more and more insights flowing in, and we’re able to ship very, very consistently. We went through, we read it the way you onboard. This is a cool thing. You need to get paid with Autobooks. You click send an invoice. We have we’re connected to your bank account. We have all of your information. We underwrite you for a merchant account. This is like technical payment mumbo jumbo, but you can accept an invoice payment in 30 seconds with auto books, and that money goes directly into your into your your checking account. Reinvented that entire thing. Changed the donation form, like I said, partnered with Apple, we now do tap to pay. You can tap the credit card right on the screen of the iPhone, which is amazing. Teams are jamming. And this is, this is my favorite picture, right? It’s like music. You’ve got product managers with insights. You got people jamming on keyboard, shipping things. And life is, is good.
The bad thing is that we grew, this is the curse, more partnerships. Again, we went from 100 banks to 1500 banks. We’re in top 10 banks which require tremendously complex integrations and maintenance and things like that. And the engineering team ended up with bugs, maintenance projects, refactors, keeping all the plates spinning at the same time, and we started slipping back into our old ways. The JIRA cards feel safe. The backlog feels safe. We don’t have time to talk to you. Just get us the next thing and let us, let us work our way through it. And now Justin is going to give you the next next story that follows it.
So like Chris said, the good thing is happening. The company is growing. The product team is doing their thing. They’re framing up honestly incredible projects because of the distribution that Autobooks has at this point, we’re finding what is essentially like arbitrage, in in pretty much our own, in our in our own code base. So we’re literally seeing things. And I’ve bolded this to kind of cheat here to show you what the problem is that are showing like if, if we, if we just changed the way that our users accepted our terms of service, we could really quadruple the number of users that we have in our system, right? Are like, the top of funnel can go up that much, but we just need this, like, simple UI change.
Justin Dickow
So a product manager is going to shape up a project, say, like, this is huge, like, but it’s simple. So we have a, you know, we have a four week appetite to do this and, okay, like, we’re gonna kick off a project, and what ends up happening is the engineering team kind of just, like, sends that back. Like, do do more work. Like, simple, isn’t it’s not simple. The one we really love talking about the I think it ends up getting minted in our actual system. It gets called, get everyone in the app. We literally call it that.
Basically, what somebody discovered was that, because of the integrations that we have with our bank partners, we’re doing this weird duplicate work, and in a very interesting order, you sign up for an Autobooks account, and before you can send an invoice, for example, because you want to get paid, we’re going to ask you what we basically call the mortgage application, which is, we’re going to ask you 55 questions. We’re going to ask you for your social security number. We’re gonna ask you for a bunch of stuff you, weirdly, have no problem typing into a form on the internet the seriously, but we don’t need to be doing that. This isn’t like a thing that converts well, right? So you just landed in your bank account. You said, I wanna send an invoice, and what you got put in front of you in your banking application is another mortgage application, basically.
So what ends up happening is we start to look at some of the data that we have, and we’re saying like we can 5x the number of people who can just send an invoice, if we could just basically leverage the integration that we already have with the bank. So product is framing up these incredible opportunities. So for this one, we there’s a project gets framed up. We say this is big, so we have a six week appetite to do this. Here’s what we’re going to do. We’re going to auto submit the the onboarding forms that are in our application. And when the user hits that, send an invoice button and they accept our terms of service, they’re they’re not going to need to provide this information because we already have it.
Essentially, one of the product managers at Autobooks, shapes up that project, puts it all together in a beautiful pitch document. I’ve already been doing shape up for five years at this point. These this document is at par with what I think is, like, a good document, and like, the engineering team should be, like, super excited about this thing. And what do we do? We schedule a kickoff meeting. You’re going to hear, yeah, we’ve already talked about kickoff meetings. So they they get slaughtered, basically. We start hearing things like this. That’s a legacy API you’re talking about changing. Our new policy is we have to port that API over, so take your six weeks, and add four weeks to it, and we can do this in 10 weeks. Oh, anyone is anyone familiar with getting comments back like this? Okay, so, just as an aside, by the way, because I don’t want to, like necessarily say that this is an inherently bad thing. What’s bad about this is, is the framing, right? What this is basically saying is the engineering team is going, we know, because we’re smart people, that we have to do this thing, but we’ve framed it so poorly to the rest of the organization that instead of actually having dedicated resources to be able to go after an opportunity, we actually need to, like, do this skunk works thing, where, when real work comes in, we need to, like, slot the other work that we need to, that we know needs to happen into there. So that’s a leadership problem, by the way. It’s not an engineering problem.
Chris Spiek
The only other thing to add here, again, because I’m just obsessed with this Pixar thing now is this is us facing extinction. So the backdrop of this, right, is lots and lots of conversations between product and engineering are going on that have this exact spirit to them. We’ve slipped back. They’re in maintenance mode, and now we’re coming with opportunities to say what your stat was 5x enrollment, right? Nope, not good. Not good. Not good. At the executive level, at the board level, we’re saying we’re not shipping anything. Months are ticking by. We’re maintaining our system. But it doesn’t matter if you have a small series B startup that is really good at maintaining your infrastructure, you’re dead. There’s nobody wants that that business, right? You guys are great at fixing bugs and keeping the lights on. Who cares? But you put a 5x growth multiplier on the board. If you’re not able to accomplish that, you don’t raise, you don’t get to where you’re going. So this is like we need to overcome this. We need to make sure that these sorts of conversations just go away and then we’re able to get back into the mode of shipping.
So one of the meetings that we usually see too, so there’s the kickoff, and you get this, you get this push back onto you on the kickoff. The other thing that we saw that was happening a lot people would schedule, essentially, what was called a de risking meeting. And actually, if you have read shape up, or read shape up, I think this is one of the ones that I would caution against doing.
Justin Dickow
But basically what would happen is and a product manager would schedule 30 minutes with an engineer, right, not enough time to do any actual work. And the, it’s true, and the point of the meeting was, instead of like figuring the thing out, the real details of the problem, what would happen is the product manager was asking the engineer to de risk, which, at its core, basically means, can you tell me that this is something that I don’t need to think about because it’s not high risk, right? Which is almost never the case. The opposite thing is the good thing, like, Can we, can we go deep on this and actually figure the thing out and answer the questions?
So when it would come to the kickoff meeting, you would get a you would get something like this from the engineering team. There’s 30 integrations. So I’m talking about, right, if we just take advantage of the data that we have at the bank. Well, guess what we’re integrated into. We have 1100 different types of data that we’re getting from these banking integrations. There’s 30 integrations, right? So the engineering team is basically saying, this is, like, this is more complicated than you’re saying it is. It’s not get everyone in the app. There’s something else going on there. Like, you have to go back and figure that out. And the and the product team is basically saying, Well, I de risked this with you. Like you said that was something that we could figure out in the six weeks during the project. And there’s this conflict here.
I’ll give you one more. This is my favorite one. We have to rebuild everything, but once we do, this will be really, really easy. So these, and these, by the way, came from like interviews with with product, with engineering, we do the jobs to be done thing. So this is another one that you hear. It’s easy, but we need to finish rebuilding our CICD. We’ve got to migrate to Kubernetes, Kubernetes first, and we have to deprecate our custom feature flagging. Like, why are these things coming up in what Chris said, like, we’re trying to 5x our growth here. This is, like, it doesn’t make any sense.
So this is what we basically call the breakdown. Every interaction here is just super it’s high emotion, basically. So I’m again, coming from essentially the same v1 of shape up that Chris came from. I’m baffled. We had teams where we felt like, you take the and I actually I know why I’ve been introspecting about this a lot recently, why we never saw the thing is because we never saw the same level of growth that Ottawa saw. So I don’t think we ever actually got to the breakdown. We got close.
So there’s these high emotion interactions, like all of the conversations are no longer about, like, what can we actually do to kind of get through this and make the progress that we need to make, because everybody is super busy now. There are true bugs. There are like, real customers are being impacted. We just, we can’t, we can’t spend the time to basically unpack this work with the engineering team. It was very much a if I’m the one bringing you the problem, then it’s, then it’s me that needs to figure out what’s going on here and the real details of it, so that when I hand over the work, the engineering team can has a very clear direction of where they need to go.
Chris Spiek
This is the critical thing that changed in our situation, v1 we had an engineering team ready and willing to engage. Here’s an idea, right? We need this payment link. Engineers are available. There’s still bugs, but we’ll come to the table. Let’s unpack this with you. Let’s figure it out. Let’s do the work together. You change this to the situation that Justin is describing, where things are piling up, things are on fire. We need to maintain this stuff. That same interface doesn’t work. You come with an idea. Hey guys, let’s pull this apart and work on it together. And they say, not defined enough, not good enough. Go back to the drawing board, and it just binds the whole thing up.
Justin Dickow
So what do you do to know that you have this problem? You go into JIRA and you go, Okay, if you’re not, if we’re not working on the project that I’m putting in front of us. What are we working on? Right? It’s not one JIRA project. You go into 50 JIRA projects, hopefully none of you ever have to learn JQL. But we probably, we probably know it better than than we should. There’s like, a there’s a lot of shit going on. It’s not like no work is happening. It’s all these tickets. Like, if you look at it from a velocity perspective, some teams do story points. Some don’t. They’re shipping tickets, and they’ve essentially fallen back to they’ve fallen back to the scrum, because that’s what feels safe to them.
So I was thinking about this a bit. I call this basically, I don’t know what I’m gonna actually call this, but since first talk, I’ll make up a name. I’m calling it the duplicity problem, basically, not in the sense that we’re being duped by the work that the team is doing, in the sense that they’re duping themselves. And you can tell that you have this problem very simply, if you look at the amount of in progress work that your team is doing, and the number of things that they’re doing is bigger than the number of people that are on the team, then you have a problem. If you’re working, if you’ve got, if you’ve got a person working on five things, guess how many things they’re working on? Zero.
This is a hard problem to uncover. So having more in progress work than like your ideal amount of in progress work that you should really have is somewhere closer to the number of teams that you have, not people, right? So, and we’re talking about, in some cases, we do see people have six, seven things that they’re committed to that they need to get done. Do you want to talk a bit about actually pulling this up? And.
Chris Spiek
Yeah, the only thing so I think this harkens back to what Justin described in his role. It’s, he’s a product person doing engineering or is an engineering person doing product? You need to be involved in all of it. So what I did was that JIRA export actually went in, everything was on fire, dumped everything that the team had checked off for the last 90 days, and just did very simple Excel spreadsheet analysis, but not through the engineer lens, through the product lens. Basically saying, I’m going to code this, and I’m going to say, what does all of this work add up to in terms of business value, right? It’s not to be dismissive of bugs or improvements or infrastructure or things that you know need to, need to happen. But basically, to Justin’s point, we’re running around like our hair is on fire. If that’s the case, it better result in something. So again, we don’t, we don’t go extinct.
And what we found out was basically 75% of the work was was just meaningless. It was flowing through customer support. Would call in engineering and say, Hey, this customer has been with us for a long time. They’ve got a bug that’s going on in some weird part of the software. If we don’t fix this, they’re going to churn. It would happen over and over again. And again, back to the same thing. We can fix all these bugs and keep all of these small businesses, but are we going to grow and are we going to continue to evolve? Are we just going to save the 100 businesses that we have on the on the platform right now? Somebody needs to step in and basically say, this hurts, but things that are a priority, our priority, and things that aren’t need to stop. And you basically burn that, that whole thing now. So it was, it was actually just a very simple from JIRA into Excel, and then, hey guys, look what’s going on. We need to stop the madness and just push, push all this work to the to the side.
Justin Dickow
If you’re a product team and you’re practicing jobs to be done, you might actually do this really well, which is, you’ve got some database and HubSpot or Salesforce or whatever, and you you have a basically a list of the like feedback that you’re getting from your customers. Imagine if you because something made it into that list, you were somehow committed to to doing it. Right, the the list of things that are ending up in a engineers backlog, they they feel committed to doing that work. They don’t use it like we use it on the product side, which is that signal for me to figure out if something deeper is going on here. To them, it’s, I just need to fix that, and I can, I can move on. So where did this actually break down? It was, it was a bigger version of the same problem, which is the engineers, they can do the work and they can unpack the work. I’ll say for the product team as like a little bit of a foreshadow, when they can focus, right?
So if I give you a project, and it’s a six week project, and you basically say, Well, I can do your six week project in 10 weeks, because I have all these other things that I need to worry about. I haven’t actually given you six weeks, because when I look at six weeks, I really mean like uninterrupted six weeks worth of work. So there was a lot of compensating behavior here on the on the engineering side, we found projects, I named a few in the quotes of like things that people were doing to try to get ahead of our scaling problems and our growth problems and things like that. But these were like unframed problems that the business didn’t know about and the business didn’t understand could be valuable if we dedicated resources to them. And so they started being interwoven with the actual like work that the product team was doing.
The same thing started happening. It’s not it’s no longer just product that I have input from. I’ve got implementations. There’s a million banks that we need data from. There’s every different bank has a different way that they want to integrate Autobooks. We have to do all this work to get all these banks live. So all these things start adding up as you grow. And the thing that you lose if you don’t put the energy back into the system, because we talk about this entropy all the time, is you lose the ability to focus people, just they go back into chaos, essentially. And for the engineering side, that’s basically drifting back to Scrum.
How we did it (2 steps)
Okay, so we’re basically a different business. We’re growing. We again, need a new input that engineering can use to actually produce work in the new reality. What do we actually do? And I promise, because instead of giving a whole framework, which I think would be like an eight hour, an eight hour, talk about how we do this, I’m going to just give you two. I won’t even name the frameworks.
In the version that Chris described what the product team was doing, basically what was happening is the product team does what they call shaping. I named the framework. It’s basically taking it’s creating the general bounds to the solution that you want to ship, and then saying, here’s how much time I would like you to spend doing that, and make the trade offs within those bounds according to the amount of time that I’m giving you.
The first thing that we did was we took the that concept of appetite and we took it to the extreme, right. Which meant what the product team is ultimately responsible for is defining the problem or opportunity that the business has. And as a leadership team, what we were responsible for saying is, how much time and money are we comfortable or willing to invest in taking advantage of that opportunity.
And then, instead of the product team coming up with the solution, we’re basically saying, figure out what you can do and give us the options that you can use within that budget. So that’s, that’s number one. So asking the question, basically, okay, this thing is worth I don’t even know what the solution is, but the problem is, is so crisp that if you can solve that problem and take advantage of the majority of that opportunity, then I would give you six weeks right to do that.
So what if we just don’t worry about these other 25 and is it difficult for us to not worry about those other 25 let me go into the code. Is this something that I can feature flag? Those types of conversations are now happening up front, right during the shaping during the we’re actually figuring out with the product team what we’re going to do. And essentially what ends up happening is there’s basically two things. When the engineer does this with the product team, the output, which is not as important, is a project that the engineering team can work on, and they know that because the senior engineer said that they can, and we haven’t even committed to it yet. The more important thing, though, is that the outcome here is the product and engineering team have already agreed on that it’s possible and what they’re going to do before the business has even said that we’re gonna do it. So we have a bunch of examples of this right now, and people are like, hungry, like, I want my project to go and I’ve and we’ve got engineers doing the exact same thing, basically, that thing that we just shit, that thing that we just shaped together. I thought, are we going to do that? It’s like we’re thinking about doing it.
And then the second part, the crux of this, how do we know what we can do in six weeks? We took a senior engineer, like a very senior engineer, and we dedicated them to working with the product team after we had a defined budget or appetite for a problem, to figure out what the options were, not what the one answer was to do in six weeks, but to figure out what all the different ways that we could take advantage of that opportunity or solve that problem Within the time. So in the onboarding example, we had the quotes like, well, there’s 30 integrations. When the senior engineer gets in the room and has access to the production database and all the logs and everything like that, they can basically go, Okay, you’re saying that you need. Like, if we take advantage of this. We’re going to get we’re going to 5x our growth. They’re going, Oh, well, we have these 30 integrations. If I query the database, I can tell you right off the bat that most of the thing, most of the enrollments that you’re talking about, are coming from these five.
Chris Spiek
This is the pivotal thing. So we’ve got engineers that we’ve moved into the senior we call them principal or staff engineer roles, and the work happens in these working sessions. So again, moving from appetites, from estimates to appetites, moving to fixed time and variable scope, and then doing the work that Justin just described, where we’ve got teams of people, we these are the most exciting meetings in the company. And like Justin said, it’s not a 30 minute meeting where product and engineering, hey, what do you think of this thing? Okay, go ship it. These are two hour, three hour, four hour working sessions of let’s go through some jobs to be done, interviews. Listen to the emotion, the anxiety of the of the user. Let’s look at the opportunity and figure out what we can, we can do together. And then the last image that you had was fantastic, right of the back and forth of, okay, you’ve got this idea. Let me go into the database and figure it out. Okay, put some post it notes on the wall, because there’s five integrations over here and there’s 25 over here, you as the product manager, need to go figure out what’s important, right? And we can work through all these, all these different scenarios. When you get that merged, along with eliminating the paper shredder. You truly get this, this stuff, unstuck.
Like Justin said, we had an hour. We covered as much of this as we can. If you want to get into the details, we have a lot of this. You can do all of this in the lucid where you can get your teams unstuck and working together and actually plotting out projects and sort of moving and shipping faster and faster. And we can go all the way down into the details. But our hope is that you’re not hitting the mark. You now have something to reach for. You can pick up Ryan shape up book. If you are truly stuck and you’re in that situation, you can talk to us. We can help you get unstuck.
There’s this interesting thing that happens at conferences where I go to breakfast in the morning, and I see somebody I haven’t seen in 10 years. How’s it going? Oh, it’s going great. Everything is and then I see him at the bar later, after one or two drinks. It’s like, we’re really trying to figure this out. And then there’s another version. It’s either late at night after a lot of drinks, or it’s like my friends back home, who I really know we have not shipped for 12 freaking months, and our customers are churning and things are bad. And what we’re really trying to figure out is, if you’re in that situation and the teams are bound up and you need to get unstuck, we have tools that you can reach for to do it. Not easy. Like moving people from different teams, completely redoing the way that engineers work. Getting rid of JIRA in these situations is not an easy thing, but you need to get a little bit unconventional if you’re going to swing that pendulum back from being completely stuck to to moving again.
The next slide is the goal. So we got through the second wave right? First Wave was not hitting the mark. Second one was being completely stuck. And then this happened, we brought a new junior mid engineer, junior, junior front end engineer on board was in the company for three weeks. I called them to just do a little check in, you know, like, how are things going? You like, an Autobooks so far, tell me about the team. And this was the quote that he gave me. Immediately started working on a process. Project that had value. None of this, like, go learn the code base, fix some bugs, and like we’ll see in a couple weeks, immediately started with the project that would add value, shift on time and because it had value, our CEO thought it was important enough to say this engineer shipped this, Ethan. Ethan shipped this. He just showed up. He’s already adding value. And to this junior engineer, it meant the world. I got in. I knew what the customer needed. I was able to influence things and make trade offs. I wasn’t just, you know, sort of taking, taking tickets, and we’re back to shipping.
Justin Dickow
So I wanted to say one thing about how the what it looks like when the problem actually gets solved. So we do all hands every few Thursdays, or something like that. And the engineering meeting, I hold one, one standing meeting, sometimes with the engineering team, we do, like a weekly meeting, basically. And after the all hands, I basically always ask, does everyone know, from what the CEO just said or what Chris just talked about? Like, how what you’re working on maps to what those things are? And the answers that I get now are, yeah, like, those are the things that we’re working on, like that bulleted list of what product is doing. Those are the projects. There’s no like, there’s no disconnect. It’s the same language. The CEO names the project the exact same way that the engineering team names the project. That’s when you know that you’re aligned on what you’re building and what you’re going after.
Chris Spiek
Get in touch. Reach out if you’re struggling with something similar, happy to help, happy to talk. It helps us learn more stories and more edge cases for all this stuff. But thanks. Thanks for your time. Thank you.
Chris Spiek
Chris has spent many years building great products based on the JTBD, with a special emphasis on empowering web developers.
With a background in web development, interactive marketing strategy and disruptive innovation, Chris has a long career in making the internet pay. Simple as that.
Justin Dickow
VP of Engineering, Autobooks
Since joining Autobooks in 2021, Justin has led a successful transformation of the company’s product and engineering practices by connecting the teams on customer and business outcomes. Before Autobooks, Justin was Head of Engineering at Tweddle Group, where his team pioneered a content development, management and delivery platform utilized by millions of car owners and technicians worldwide.
Next Events
BoS Europe 2025 🇬🇧
🗓️ 31 March – 1 April 2025
📍 Cambridge, UK
Spend time with other smart people in a supportive community of SaaS & software entrepreneurs who want to build great products and companies.
BoS USA 2025 🇺🇸
🗓️ To be announced soon
📍 Raleigh, NC
Learn how great software companies are built at an extraordinary conference run since 2007 to help you build long term, profitable, sustainable businesses.
Want more of these insightful talks?
At BoS we run events and publish highly-valued content for anyone building, running, or scaling a SaaS or software business.
Sign up for a weekly dose of latest actionable and useful content.
Unsubscribe any time. We will never sell your email address. It is yours.