Posts in category 'prodmgmt'
Turning the page
After 21 years in my job at INVIDI I realized I needed a change, and in that moment of change, some space to reflect.
The beginning
Twenty-one years.
For many of the folks I know, twenty-one years is a long time in a career, let alone in a single company.
But the strange thing is that, while on the resume it looks like I’ve had just the one job, in reality I had the great fortune to have experienced a remarkably diverse series of roles, and it seemed like every time I started to get a little antsy, a little bored, in need of a change, INVIDI offered me another opportunity, another challenge, another path to walk.
And it has been quite the journey, though one that has come to its natural end.
Continue reading...Chesterton's Fence
The last few months have me thinking a lot about technology, disruption, and the metaphor Chesterton’s Fence, or why you need to think about systems before reforming them.
Back in 1929, G. K. Chesterton, an English writer and philosopher, described what is now known as Chesterton’s Fence, a metaphor about reforming systems:
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, ‘I don’t see the use of this; let us clear it away.’ To which the more intelligent type of reformer will do well to answer: ‘If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.’
In the context of his writings, G. K. Chesterton was using this as an argument in favour of certain socially conservative views (hence the title of the essay “The Drift from Domesticity”). But the core principle–that it’s important to understand systems before you change them–is far more broadly applicable (and apolitical!), and is something that I think the technology industry would be wise to adopt.
Continue reading...Five years in Product - The Team
The third in a series on my years in product management. In this post I explore what it was like to help build a product team, and then work within it.
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...Five years in Product - Leadership
Continuing my little retrospective writing exercise on my journey in product management, in this part I wanted to talk a bit about my (bumpy) path to better understanding the nature of leadership.
This is part two on a series of posts on my transition to Product Management. If you’d like to see where this series began, feel free to checkout part one.
As I’ve gone back and looked over some of the email traffic from my first couple of years in my role as Product Manager, one of the most obvious things that stands out is just how much was going on at the time (and how little I’ve apparently retained)!
The backdrop of this period was a parallel effort in the company to:
- Modernize our software development practices by moving to a process built on Agile Scrum, and
- Shift way from our custom, consultative software development model to a product-centered approach focused on broader market needs.
Either one of these would be a large, challenging transition. Looking back, attempting to tackle both at the same time was borderline insanity!
Looking more closely at the transition to Product-oriented development, this is also seems to be a pretty common phase in the startup life-cycle.
As I’ve talked to other folks in the industry, I’ve noticed that many startups, particularly those in the B2B space, initially succeed by developing a solution for a couple of “whales” that serve as an essential lifeline that keeps the company operating. Over time, as those successes beget more successes, the company can step back and focus more on the market than individual opportunities, and at that point, a pivot to a Product-centric development process makes a lot of sense.
The trouble is, this is often not an easy transition. Ignoring the challenges in shifting the entire mindset and culture of an organization, there’s the basic politics of handing off responsibility for feature selection and prioritization from technology leadership to product leadership. As you can imagine, this transition can be very difficult if not handled delicately.
Continue reading...