When adding features to a software product it's easy to underestimate the overall time and cost they may take up. To keep the full impact in mind it can be helpful to think of Features As Pets.

When I think of Features As Pets it helps me look past the initial cost of designing and developing a feature and consider its full lifecycle. For example:

you're going to want to tell your users about it

you'll want to check it's being used as intended

you'll need to support it and check that it works in all different places and fix it when it breaks

you may need to work hard to make sure it's compatible with new features you add

you may have to return to the code and refactor it to improve performance

you may need to upgrade libraries and maintain security patches

finally you'll have to decommission it gracefully when it's no longer needed including dealing with data you may have stored

New features are probably one of the key differentiators of your offering compared to others, but it bears a little consideration before adding something — a feature is not just for Christmas.

Features Are Like Pets is from the excellent Intercom on Product Management podcast (Apple, Spotify, ebook).

Features are like pets

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for how to think about what to release to your customers when. Hopefully it’s self-explanatory, but the idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not, when explained like that, so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. At the beginning they’ll probably have to put up with a lot if they want to use it, but with each successive release they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning and all along the way the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it usually involves some rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

HT: the brilliant User Story Mapping by Jeff Patton and Kevin Alves

A release strategy for happier customers, sooner

Shares information passively, with the neat effect that having a good one in an office can go a long way to getting people on the same page without explicitly calling meetings or sending out updates to do so. Handy to also have a good space in front of it for talking, discussing and generally collaborating. A common term in agile development, originally I believe from Alistair Cockburn of Thoughtworks. To quote from his article, of many possible:

- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date”

Information radiator

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Sketchplanations tagged with agile