S01E04 - Which digital product process or methodology is best for me? Transcript

Drew: Welcome to the differential product conversations podcast where we try to demystify how great digital products are made by answering questions product owners have but are too afraid to ask.

Colin: Alright, welcome back. So the setup of this episode is that we know digital products are hard, you know you need a team, but now how the heck should we work together? What process should I follow? 

Our goal for this episode is talk through the big different options, the pros and cons of each, and then maybe come to some realization of something that is helpful and not that we talked for two and a half hours on the different methodologies and processes that we can use.

First, set up is why do we need a process? I'll just set it up, I’ll answer this one and then I'll flip it over to you, Drew, to talk through what are the bigger, popular ones. 

Process in digital products is super helpful because you have to know where you are and where you're going. And then it also answers the question of “is my team working well together?” Do I know we aren’t just kind of spinning our wheels and not making progress? How do we not get caught up in what the process is and how we make sure our focus is still on the digital product? 

I know there's a bunch of options and methodologies out there, Drew, but can you give us the highlights of what are the big ones that people are looking at in those modern, today digital product development?

Drew: Yeah, totally. I'll try and keep this as brief as I can. I'll run through these quickly and talk about principles behind them, benefits, and trade-offs. So why one of the first ones you can think of that's a little more antiquated at this point (hopefully we're moving in more ways) is what's called a Waterfall Approach.

It's usually not seen in a positive light. Normally it's looked at not in a necessarily bad way because it can work in some environments but just sort of less than ideal way for building great digital products. 

So the key principle behind a waterfall is the sequential design process. You can think of it as I have a designer or a design team. They create a mock-up. That mock-up is done to spec, and it's completed and then handed off to the development team. And that development team then builds it. It's isolated, it’s kind of these different swimlanes that the feature or the functionality is moving through.

So I guess benefits to this approach could be that while team members are able to do their work and move on… it’s kind of one of the only real benefits I could think of, but there might be some other ones and then trade-offs here.

Colin: This one's really prevalent if you think about construction. That's kind of where it came from. The military instruction use waterfall methodology a lot to say Hey, we're going to do the thing and then pass it over, more of a conveyor system of the Industrial Age of things like that. And so it was just applied in digital products early as software as, hey, this is the best thing that works in other things. Let's try it. And that's where it's kind of going out of favor. It’s like, oh we're understanding the nuance of digital products that maybe this thing isn't ideal for this kind of software, digital product environment.

Drew: Yeah, that makes sense. It's the assembly line kind of process, too, where there are obviously trade-offs in collaboration, I think is one. There's this key moment for “Handoff” where you're taking the design and giving it to the developer and there's a little bit of communication there, but it's not really truly coming together in a cross-functional nature to build something.

It's the trade-off you're making in collaboration. I think design can end up worse in some senses because you're designing to a spec versus letting it evolve and be shaped by the team working on it, which is a huge part of digital products. And then I think there's just a disconnection between the different parts that make it difficult.

So then after Waterfall, another real popular one is Agile. Agile initially started as some basic (I think it was 12) principles of building Agile software, and it was called the Agile Manifesto. It’s blown up past that just into all these different variations and nuances around it. 

But in general the key principle behind Agile, the definition is that it's a very collaborative environment with cross-functional teams that self-organize. And it's a little more organic; the benefits of doing this is you're empowering your team, you're giving them more responsibility and accountability for making decisions about scope and refining features and all of that.

And then inherently you're increasing collaboration. So different from Waterfall, Agile is giving you more of a connection with your team. Because it's cross-functional you're working together to build this thing. 

And then obviously trade-offs here could be that you know, it's predictability - you kind of sacrifice a little bit about what is going to be built, if you let the team sort of shape it. I think there's a high need for lots of communication across the team because if you're not communicating well, you can't really organize these cross-functional teams and do it in an organic way. I think it makes it really hard if you're not communicating properly. Those are definitely big potential trade-offs with agile. 

Scrum is another one. It’s really more of a process for Agile with Agile being the methodology. So I won't go into it too much. It's more specific roles like Scrum Master.

Colin: Can I become the scrum Master on. That’s what I want to be.

Drew:  I think that was the thing. They just wanted a title that sounded really cool so that you can —-

Colin: It’s something you can go to training for and then you become these cool titles, but I'm like, they're bad.

Drew: I'd introduce myself as a Scrum Master. So I think that one falls into the same sort of principles and benefits and trade-offs of Agile.

Another popular one that I've heard is Extreme Programming. I mean, I think with all of these actually they're all - most teams are doing all of them in some way. I think Scrum is kind of an interesting way and Waterfall… some of them are isolated, like, “we do Agile this way with Scrum,” but a lot of these blend together in some way.

Colin: So is it more like there's two big ones today and where people are coming from. They're coming from a traditional Waterfall approach because that's what they've done in other industries, other things. That's kind of the project management Gantt chart kind of dependencies, just do these things next, here’s when other people can get in line and 

Then Agile, this kind of collaborative work environment. But there's this process. There's people collaborating which means people are going to be in collisions. And, people colliding can be good and bad there. But, it allows us to (determine) what's the next big scope of work and then let's do that. And, then lift your head up and say, where are? We make sure we're still pointing in the right direction, which we work on next based on what we've known and what we learned during that thing. And, then there's tons of different kinds of facets of how to approach how to get that collaboration.

Is that kind of what you were thinking?

Drew: I would say for sure. I think it's if you had to have a 10,000-foot view where the categories fall, I think waterfall is one side and agile the other side. Then agile, because it's such a slim down kind of like “Hey, we're all working together on this cross-functional team. We're going to shape this thing together.” Versus (Agile) here's the spec send it down the assembly line. So I think that is a good way to kind of hit those two things against one another.

Colin: So then Drew, why don't we talk about our process,  because you are doing a lot of our process stuff like this. It's the high-level of like what is our overall process? And why did we choose this process? And what are we? What are seeing and why we like that?

Drew: Yes, I mean, I think this is something that you just have to treat your company like a product and that's what we do. And I know this is a lot of our thinking you know and stuff is coming from great companies like Basecamp. So they build the Basecamp, a project management software, and they're also called Basecamp. They run a company and write a lot of material. Write some books and they have a lot of product thinking out there that has helped shape a lot of things and I think it's different. 

But for us, you know, we treated our company as a product and our process is that so we're constantly iterating on it. So what I say right now is probably not what it will be, you know, even in a couple weeks from now, it changes all the time and I think that's that's the fun part. So really if I could just zoom out on what our overall process looks like. For us, there needs to be an established product vision.

So, we need to know what we're doing. What's the vision of this thing? What user problem are we trying to solve? That's where the digital product is born. That's what we do. We have different processes in place - you are doing design sprints and proof-of-concept work to try and validate that and de-risk that initiative.

And then once we feel good about that, we're able to then build a product roadmap that outlines what problems are we solving. We need to start putting some time on it because that matters, time matters. 

When are we going to get this out? How much is it going to cost? So we break that thing down figuring out all the different pieces and isolated scopes of work that exists and writing out, these “user can” statements with all the end-user, and end result things that can happen.

You know, figuring out estimates and all of that but really having this product roadmap, which should always be shaped and I think we try and limit it it's you know, three to six months. But even if you get past three months it starts to get hazy because if you're really building great digital products, like I mean part of it is you need to respond to user feedback.

So they need to shape that roadmap. You may have a hypothesis. That's kind of what I see a road map as it's like, I believe these will solve these problems, but maybe they're not the right problems when we actually get there. So I think that's where the agile methodology comes in, you know adapting to.

And then once we have this product roadmap, we kind of figure out what are some different, you know, groupings and themes that we're seeing solve user problems. And you know, how can we group these into releases or software releases or versions or whatever you want to call them to kind of break that down.

And again, this is about getting actual features into the app because you again have a hypothesis that I think this thing will solve this problem, but you need to release it and do it as quick as you can with as few changes is possible to test it and then iterate on it from there. 

So once we're at that stage, we are kind of just assuming then we have a product team built around this. So we figure out the right number of you know, designers and developers and product management product lead. Who can basically work in an agile fashion and work in what we call cycles, which again came from the Basecamp folks. So they work in those cycles too. A cycle is six weeks. 

So the very traditional agile approach is that you do Sprints which are two weeks at a time. We still do that as a means for tracking progress because we think to wreak increments are great. And we work with our client Partners and being able to show them progress every two weeks, that's important. So we like that cadence for moving things forward. But, when we look at the bigger picture, cycles or where it really matters. That’s six weeks is a great time unit for delivering value against that roadmap. Whereas a sprint is really isolated. And you know, you say a two weeks sprint but really that's 10 working days and then you have a day for planning you have a day for shipping things and testing. It really starts to shrink down the number of days you actually have to do the work. 

So, looking at six weeks we break that roadmap down into those six weeks cycles. And then keep making sure that we're hitting those objectives towards that cycle and two-week Sprints. Then really just rapidly delivering features and continuous delivery approach within a sprint is sort of where we end up landing. So we're making these small incremental changes day-to-day, week-to-week, month-to-month and it bubbles up to this larger roadmap. Which bubbles up to the larger vision. So it kind of gets this bi-directional flow and it works really well for us and we're continuing to refine it

Colin: Cool. Yeah. So we always start with the vision to create a roadmap, break that down to releases, the releases come up from cycles and Sprints in terms of how we get that work done and we use a product team to do that.

So it's good. Yeah, I think we probably hopefully cover this answer enough of like the different process things of development of building a product there. So the takeaway is like there's again a handful of different different different development methodologies that they kind of ones are difference between waterfall and agile, 

I think the big takeaway that we would throw out there is a lot of these are just different tweaks of those things that somebody put a label on and says is better because they found it better in a certain circumstance. But, they also maybe want to sell you training or certifications or something. So it's like, don't get caught up in that. That's not the key thing. What works for your team? And, do you have a general agreed-upon process to build digital products? So the process shouldn't get in the way or distract you from focusing on the users.

The users are way more important than the process. The process just helps and makes you more efficient as you go through it but it's not the be-all-end-all, like, “Did we have our meetings for the daily stand-up at what time? And how many did they hit? You're gonna get lost. You're not actually building the right features and things like that.

Thanks for listening. As always, we want to hear from you. So please reach out and give us your questions and challenges. We will try to address them on a future episode. You can reach us at podcast@differential.com or you can find us on Twitter at @BeDifferential.