On Product Management

By Jake • July 1st, 2009 • View Comments

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

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.


Possibly Related Posts

  • Jon Frame
    I would like to try out the app.
    Can you send me a link?

    Thanks,
    Jon Frame
    Raleigh NC Office
    jon.frame@oracle.com
  • You're in an interesting situation, since your customers do not directly pay to use your product (although perhaps the Oracle accountants allocate costs to users in some internal way). I'm in a different case, where my product is sold to paying customers in a market - a relatively small market (even optimistically, our market is in the thousands rather than the millions), which means that individual customers have a great say in the direction of the product. This results in a somewhat different dynamic in relation to the strategic direction vs tactical customer requests question.
  • Sure, money does change the equation. We have a similar dynamic among teams that have lobbied large groups to use Connect. We have no marketing and rely on viral adoption. So, when large orgs/teams make the jump, they tend to have a larger say-so in the product direction, which makes sense.
  • My colleagues and I went on a strategy planning type of meeting for a few days and thought strategically how to improve our business within our roles. I am in Product Management .

    We found gaps and filled the holes and now are working better as a team.

    I found this book, “Reinvent your Enterprise through better knowledge work” by Jack Bergstrand and thought this would have helped us even more then but at least we can focus on the now and learn faster and better ways to improve our knowledge and work productivity.
  • Thanks for the tip.
  • Jake, first off I have to say how refreshing your blog entries and TheAppsLab is from an organizational perspective. Kudos and thank you!
    Regarding your post, I have a couple of thoughts. First, what about donating Connect to oss.oracle.com? It sounds like once Rich and Anthony are done cleaning it up, you would have something worthy of submission. Doing this may actually provide many benefits to Connect, Oracle, and TheAppsLab. For Connect, the OSS benefits are pretty obvious from the number of contributors that you have the potential to garner. It will also give Rich and Anthony an opportunity to practice crowd-source product management :-). For Oracle, it shows our continued willingness to not horde innovation and ability to provide significant benefit to the community at large. And for TheAppsLab, it is just another example of justification of the benefit of the group.
    This leads to my second point, that by giving Connect to the OSS community, it frees a majority of TheAppsLab team's time up for continuing to innovate. As a Sales Consultant, I am still struggling with ways to tie Social Networking into my daily activities. My personal goals are to be able to earn Trusted Adviser status to more customers, build more qualified pipeline, and stay more in touch with both the business and technology worlds. I think that as a group, all Sales Consultants would want the same thing. How would TheAppsLab begin to approach better defining the problem so that we can address it using current and future technology approaches. I would be very interested in being actively involved in such an effort.
    So, short and sweet... AppsLab:
    1. Keep up the great work!
    2. Give your work to the community!
    3. Create new products!
    Cheers,
    Jordan.
  • Thanks for the kind words.

    From the beginning, we've wanted to open source Connect, and several people (customers) have expressed interest. The problem is that I'm not sure how to do that from a process perspective. Maybe you can assist.

    Noel's release of OraTweet "as is" for free may help us build a case for Connect.

    Connect (and Mix) are JRuby apps. When it launched, Mix was the largest JRuby production app, and I think it still is, unless Connect has passed it. Either way, we've used a combination of Oracle and open source pieces.

    Also, even if we open source it, we can't fully let go of Connect until we find it a home with a team to support it. People use it for work, and we can't bail on them.
blog comments powered by Disqus