Welcome to episode 3 of the Building Bonzai Podcast. In today’s episode, our hosts Matthew Carriere (Director of Engineering & Co-founder @ Bonzai) and Chantal Cameron (Data Analyst @ Bonzai) discuss what engineering should be building, what is a minimum viable product and how Bonzai would typically go about feature prioritization.
Know what your customers are asking!
Carriere: “So today, I wanted to talk a little bit about making decisions around the product, around basically any product that you might be building. And so, Chantal and I have had some experiences on different sides of it. Me, with the engineering, Chantal, sits more at the conceptual phase.”
“Chantal is our data analyst and she work with the data that comes in and runs user studies. She can talk a little bit about that. We want to talk about some of the strategies we use to make decisions to really keep moving the product forward, rather than stalling in meetings that kill stuff.”
“Chantal, let’s start with you since you work with the data and on the conceptual side of our product. When we’re getting started with a feature, we usually look to you to say what are people asking for; would this be a good idea? What’s the work like on your side to decide about what engineering should be building?”
Chantal: “For me, it’s really coming up with the UX designer and discussing how we want to listen to our customers, and what do we want to know about what they’re asking. For us, it may be things like user studies or surveys, really listening to the customer and figuring out what they are asking for.”
“By setting up user studies and surveys, we take back that data and we analyze it and we find commonalities between all of them. Though they’ll usually surface at the top quite quickly, and that is generally because people know where the pain points are.”
“And If one person is having it, probably a lot of people are having it and it becomes very clear early on what needs to be focused on next. Then generally, I will write a report and make suggestions and present it to you guys in the engineering team, and that’s kind of how we go at it from a UX perspective.”
Know what is important
Is it Real?
Cameron: “On a higher-level, I’ll sit down, and have lots of meetings with marketing and sales and get their feedback from their point of view of the customer. Marketing, generally, has a lot of research and ideas and ways that they want to be able to sell the product, so they have a lot of high level, esoteric design ideas that are kind of trendy.”
I generally tend to sit in a lot of those meetings and discuss other things. And everybody kind of has their say, and I’ll align that with the hard facts of what our customers are asking. So, it goes back and forth, but it’s super interesting when you really get down to it, where you find the commonalities between what the customer is asking, what internally we want, and then finally, what is possible on the engineering side.”
Quick wins vs High Business Value Features
Carriere: “Yeah, that’s a big challenge of getting started on the engineering side. We get, and especially from you guys, a lot of interesting stuff. It’s across the map. One of the ways we look at it initially is quick wins.”
“There might be pieces of functionality that we’ve already built, and it’s really just making a little bit of UX or a bit more functionality and we can re-use something we’ve already done, so that’s always a good one where we can have a quick win like that.”
Is it Worth it?
Carriere: “In larger pieces or features, what we end up doing is ask what skills are required to do those; who on the team have those skills or have the availability. Then everything gets outweighed by the business value or the impact, right? If somebody’s working on something but we need their skill-set for a feature that we’ve deemed high value, we’d probably start transitioning them into that.”
“Sometimes, something that requires a high skill and a lot of work, but we can’t really get there with the business value. We don’t see any customer feedback coming back that tells us that’s going to be worth that engineering effort. So that’s always a consideration once we start getting data back from you guys.”
Can We Start Small ?
“But the biggest thing is the skills of the people involved, how long that might take, and can we do that iteratively? If we build this one part of the feature, can we release that? Can people consume it and give us some feedback on it and build on it? Those are the best ones. Because then, it’s not this big bang approach where you say, Okay, we’re going to build this whole thing, and then put it out there.”
“We’re going to get to the whole thing, but we can build these little pieces along the way and get people into it, and we could course-correct or tweak, and I think in very rare occasion, we say kill this, like nobody cares. But you know, being able to do it iteratively is probably the biggest bonus or something that really bubbles something up to the top.”
Can we Ship it Skinny?
Cameron: “How do you guys face a challenge where we have an idea that’s really being presented from customers and marketing wants it, sales needs it, but it tends to be a big project, but still needs to come out in the next point release? How do you guys whittle down how you’re going to take something as complex in functionality and try and put it within a three-month time frame?”
Carriere: “Basically, if the task has the measures or goal posts that say this must go in the next point releases but it’s really large then you think there’s no way that you do that, you really have to take a look at what I think it feels like an overused term at this point, but minimum viable product.”
“You want to look at what that core piece of functionality is that you would have to build for this to be valuable. There’s always the bells-and-whistlesversion, you know, the gold-plated perfect version. But generally, people are asking for something because they have a problem they need solving. You can get at the core piece that if you get that built, that will have impact in that point release, and then, again, iteratively, you can build on top of it.”
Cameron: “All right, so that’s this week’s episode. I hope you guys learn lots about how we go about making decisions. I mean that works for us and hopefully, it will help you guys on your product development journey.”
“We hope to see you next week. We’ll have lots of new, interesting things to say. We’re doing this on a bi-weekly basis now, so make sure you subscribe, and we’ll hope to see you soon.”