On Product Management

I’ve been in software product management for about ten years now.

Connect, my latest product, has reached a critical stage in its life. It’s the first product I’ve managed from its inception, so I’m getting interesting new experience as it grows.

It’s pretty robust and has most of the big features people need in a social platform. So, we’re trying to decide what’s next: build something new or add incremental features.

Photo by woodleywonderworks on Flickr used under Creative Commons

Our last release increased the codebase quite a bit, and Rich and Anthony are busy documenting and refactoring the code and writing tests for all the new stuff they built. I know, it’s backwards, but we pushed pretty hard to get it done on a timeline.

Since they’re tied up, Paul and I have plenty of time to noodle what we’d like to do next and what we should do next. Every product team is faced with this decision, and there is never an easy answer. So, in addition to pondering our future direction and strategy, I’ve been thinking a lot about the challenges of managing a product.Our charter is innovation, which is pretty broad, but we’re supposed to be thinking of what’s next and how it can be used. Technically, we’re not a product team, but Connect has morphed into a product. So, we have no choice.

Once the code is stable, what should we build, more features or innovative stuff? Our team is small enough that we really have to pick one or the other, which makes the decision difficult.

More Features
Now that we have a large base of users, it’s tempting to keep adding on features to Connect. A few of the common asks: chat, nested groups, email integration and file management.

All of these would add value to Connect, but should I invest effort to build them?

The most difficult thing about managing a product is balancing what your users want with the direction you feel the product should take. You should know the direction, and it should account for what’s best for your users, whether they’ve asked for it or not.

Which is where you run into problems.

If I don’t build a highly requested feature, that doesn’t necessarily mean I’m not listening to users. In the case of Connect, we have specific constraints preventing a couple of those features. I’m transparent about those issues with users, and they accept, sometimes grudgingly.

What about the others?

This is where it gets dicey, i.e. when you and your user disagree about direction.

Requirement is a funny word in product management. It can mean something needed to comply with government regulations or something that a user really wants. Figuring out why a requirement is a requirement provides a challenge in the latter cases because they frequently boil down to opinions.

With a couple of these features, I think the investment of effort would far outweigh the utility of the feature, which takes effort away from really useful stuff.

This is a tough call to make, but it’s one that product teams do all the time. I try to be transparent about the reasons, and at the end of the day, your users should trust you as the domain expert. Unfortunately, with a social product, everyone who’s ever used Twitter or Facebook is an expert, which makes for some fun requirement debates 🙂

Innovative Stuff
I don’t really want to keep adding features to Connect nonstop for a couple reasons:

1. The codebase is big, and I don’t want it to outgrow our ability to support it.
2. Adding new features prevents us from focusing on innovation.

Innovation within your product (or outside it) always competes with sustaining tasks and building new features for users.

This is why software is hard.

So, Paul has some rad ideas that would be a huge departure for us, but seriously cool and totally new, mind-blowing type stuff. He’s the big idea guy.

This works great for me, since I’m not that guy. I’m the make-it-better guy. My ideas are practical ways to build cool stuff without mucking with Connect’s codebase–analyzing the data, creating visualizations, building a reputation system, building clients.

Nothing terribly sexy, but all models that have yet to be fully realized within large enterprises.

Decision Time
We haven’t decided what to do next yet, and we probably won’t for a couple months while Rich and Anthony clean up their code.

Most product teams try to take a balanced approach, combining innovation with incremental improvements. I’m not convinced that’s the best model, but I haven’t seen many others. I’d be interested to see how large open source projects like Firefox or Ubuntu handle this issue.

Anyway, this was a bit meandering. I just wanted to get my thoughts out there and see what others had to add.

Find the comments.