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.
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...
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...
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...
It’s been over five years since I moved into software product management and it’s been quite a ride. Given it’s nearly the end of 2019, I thought it would be fun to do a little retrospective! This is part one: the pivot.
Anyone who knows me knows that I basically grew up around computers. I began my lifetime of coding very early on, beginning with a BASIC interpreter and a library book and rapidly progressing to HyperCard, Logo, and then eventually Turbo Pascal. By high school I was one of a few obsessives who spent all their time in the computer lab where, if I wasn’t playing games or messing around with the equipment, I was writing code.
I was, in short, a computer nerd.
And, while my professional life has moved in a different direction, this still true to this day. I honestly doubt there’ll ever be a time when I’m not tinkering away on one project or another. Heck, the relaunch of this blog was as much an excuse to mess around with Jekyll as anything else…
But the idea that I would ever be anything but a “computer guy” never would’ve crossed my mind. I suspect my past self would be rather surprised by where I now find myself!Continue reading...
1 of 2