This is part three in a series on my career shift from software development to product management. If you haven’t read the preceding posts and you’re interested, you can start with part one!

When I first took on the role of Product Manager, it was basically a solo role. While I had plenty of support from our executive team, and a lot of help and direction from both my superiors and my colleagues, absent a dedicated staff, if things needed to be done, I either had to do them myself or trick others to do them for me!

On its face this might seem a bit crazy (and it was!), but it’s important to realize that, at the time, the company had not yet made the shift to an Agile Scrum development model. As a result, back then, if you had asked me to describe the Product Manager role, I would have described it as high-level and directional, while the actual day-to-day execution was being handled by my colleagues in various other departments, particularly development. As a result, a lot of my time was spent on bigger picture stuff: building roadmaps (badly), scoping releases, collecting and managing customer requests, general process development and refinement, and so on.

It’s also worth noting that, at the time, I don’t think any of us at the company had a clear picture of how to integrate a Product Management function into the company in a holistic way, not the least of which because, while this was only five years ago, the role was less defined than it is now. And as I mentioned in my first post, ultimately, layering Product Management as a function into an existing organization is an exercise in change management, and we were still figuring out what that meant.

Fortunately, Agile Scrum came along and gave us a model for how to integrate Product Management into software development in a coherent way: The Product Owner role. And if we were going to have Product Owners, those POs needed to get their direction from somewhere, and that somewhere could be the Product Management group (i.e. me)!

Continue reading...

The idea

If you’ve been paying attention to my writing lately, you’ll notice a theme. Toward the end of November I got it into my head to rebuild my blog for reasons that, in hindsight, I don’t actually remember.

At the time my main goal was to change the technology over from an old blog engine to something a bit more modern. But as I thought more about what I wanted for my blog, and read more about the IndieWeb movement, I realized my idea of what a blog could be was incredibly limited.

To their great credit, modern walled garden web services have given us with a lot of ways to express ourselves:

• Short notes (tweets, status updates)
• Long-form content (blog posts, articles)
• Photos
• Reactions (likes)
• Shares (bookmarks, retweets)

Not to mention more specialized status updates like what we’re reading, what we’re listening to, etc.

Each of these represents a piece of content we’re creating and publishing. We may not think of it that way because firing off a tweet or writing a quick status update is so easy. But they’re all just alternative formats for self-expression.

Unfortunately, as I’ve noted previously, because these are each their own walled garden, this content is split up and spread out across many services. At best this is annoying! At worst, it’s a great way to ensure that the things we write or post could get lost someday when those services inevitably die.

And then, as I read more about the IndieWeb, I realized I’d been thinking about my blog all wrong.

Yeah, sure, traditionally blogs were the home primarily for long-form content. But it’s my blog. It can be whatever I want it to be. So, why not turn my blog into the place where I post all of the things! And then, after authoring on my own site, automatically syndicate to those social networks!

Continue reading...