For every product release, our goals are the same—we want to show customers we care about meeting their needs and we want to stay ahead of our competition! So how do we get it all done? We cram as many features and bugs as we can think of. Cutting back is for complainers!
Is it really?
Or…is it hard to estimate how long a feature is going to take to build or a bug to fix? And by not cutting back are we jeopardizing the quality of the product we release and sacrificing the sanity of the team?
We get that this is an age-old struggle. It’s hard to challenge business goals and start a conversation within your team about why you aren’t going to do something without being seen as a slacker.
If you or your team has struggled to figure out what will produce quick wins, what to ignore because there is no value, and what may be too complex to pursue in a single release, then you’ll want to watch today’s episode! In today’s Build Tip, you’ll learn:
Be sure to share the episode with your teammates to help them understand the importance of cutting back!
After you watch the episode, let us know in the comment below what is your team’s go-to method for paring down features and bug fixes!
Listen to the episode on iTunes!
Poornima Vijayashanker: What’s the matter? What are you doing?
Developer: I’m getting ready for the next release.
Poornima Vijayashanker: And this is how you get ready?
Developer: Do you know how many features and bugs we have to get into it? I’m to sure we’re going to be able to make the release in time.
Poornima Vijayashanker: Have you thought about cutting back?
Developer: No way. Have you spoken to the customer recently?
Poornima Vijayashanker: I think we’re going to need to cover how to cut back in today’s Build tip.
Welcome to Build, brought to you by Pivotal Tracker. I’m your host Poornima Vijayshanker, and today I’ve got a new Build tip for you. I’m joined by Jay Hum, who is a project manager at Pivotal. Now Jay, we run into this issue over and over again where we commit to a lot of features, a lot of bugs, because we want to meet business goals and we want to make our customers happy. But we can’t cram it all in. And I know time and time again we tell people to pare back, but they don’t, right?
So let’s start by talking about why people don’t pare back.
Jay Hum: So before I answer that question, I think it’s important to bring out that software development’s always notoriously difficult. And estimating the amount of effort that goes into any type of release feature or functionality, is even more difficult, right?
So, for example, if a developer comes to me and says, “This is going to take two days,” then I multiply that two and then add two days to it, so it’s actually going to take six days instead of two days.
Poornima Vijayashanker: So why is it even important to pare down a release?
Jay Hum: So customers always ask for a lot of features and functionality, and then even the development teams, the product manager, the designers and developers, they always have their own ideas of what should go into a release or feature. But at the end of the day, until that product is out in the market, you’re actually never going to know what features or functionality the customers are actually going to use.
There’s lots of evidence out there that when you’re dealing with customers, they’ll say one thing but you go look at the analytics and they’re actually doing something else, right? So the danger in creating this big release that has tons of features and functionality, is that you can sort of create something that’s sort of an analysis paralysis in terms of what the user’s experiencing, right?
So if they get a new release and there’s so many new features and functionality they don’t know what to do, so what they end up doing is not doing anything and just going back to what they were doing originally. The second part is that you always want to sort of relate it back to web business goals or metrics that you are trying to achieve, right?
Again, you want to focus on some of the top priority task features that will drive the most business value or move a KPI, whether that is to increase engagement or move people further down the funnel.
Poornima Vijayashanker: What happens if we commit to everything?
Jay Hum: Well, in Ronan’s case where he’s all stressed out and it’s a big release, I mean I’ve heard this story before, and essentially the short answer is disaster, right? But let me unpack that a little bit.
So, first of all, you’ve already seen that Ronan’s very stressed, right? So if you don’t pare down the release you are effectively going to burn out the team. Not just the developers but the product manager, the stakeholders even, the quality engineers, and the designers.
Poornima Vijayashanker: Is there anyone besides the team they’re going to upset?
Jay Hum: Yeah, obviously you’re going to upset the customer. So generally when the team is overstressed or burned out and really pushing hard and cranking through the night, effectively, they’re not going to write good-quality code and they’re going to accrue technical debt and it’s going to be messy and they’re going to cut corners, right? So that means that the product that eventually is going to be shipped is going to be subpar, it’s not going to be up to the expectations of the client or customer, and again, they’re just going to get turned off and very disappointed.
Poornima Vijayashanker: I know there’s been a lot of conversation and debate on how to pare down features, what bugs to include or not include. Do you have a simpler solution you can share with the audience?
Jay Hum: Yeah, my go-to solution is a two-by-two matrix. That works very well in helping us prioritize which features should go into a release and which features should fall out. So it’s a two-by-two that allows us to rank any features in terms of value to the customer as well as complexity to implement.
And it’s great because it actually gives you information on four different things. So it’ll give you information on which of the features you should actually be doing or working on, as well as which would we call sort of the quick wins that you can do very quickly and looks like you’re making good progress. It’ll show you which features that you should ignore because they don’t have any value or they’re too complex, and other ones that you should debate around in terms of product strategy and roadmap.
Poornima Vijayashanker: Now Jay and I want to know do you guys have a go-to method for paring down features at your company. Let us know in the comments below.
That’s it for today’s Build tip. Be sure to subscribe to our YouTube channel to receive more episodes of Build and other great tips like today’s. And special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.
This episode of Build is brought to you by our sponsor, Pivotal Tracker.
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Category: BuildTV
