A peep I used to work with that is wicked smart asked for tips/pointers on product management. I decided to put my thoughts up here as this might help more than my peep.
I’ve worked in a bunch of shops, and these are two tips that can become a big differentiator for you…
Be an Entrepreneur/Intrapreneur
Whatever space you are responsible for, view it like it’s your own business (or could become a standalone business). If you view it this way, where you are supplying the cash to make your business successful, it might help shape your view of investment. You’re driving the product vision, which also means the investment of time/money/people to make this a reality. None of these are infinite, so you’ll have to make trade-offs on how you choose to build out a road-map and move forward.
For instance, if the Flux Capacitor is going to be your key marketplace differentiator, you may need to invest more in foundational/tooling aspects – have the teams do more research spikes, iterate on proof-of-concepts, etc. before powering the flux capacitor up with 1.21 gigawatts.
Conversely, if the product idea or feature isn’t well understood, you may choose to invest less and slipstream something less robust out the door to get consumer/marketplace feedback. For a web-based product, you could hide this behind some multivariate test to divert X% of traffic to it, and use feature flags to turn the test on/off.
Focus
None of the companies I’ve worked for have ever had a problem with coming up with “things” they want to do for the business. However, what many companies struggle with is how to prioritize and focus. Agile techniques welcome change and control costs by using a “just-in-time” methodology to prevent over-investment in requirements/features that could (will) change by the time you’re ready to implement. However, just because you can switch easily doesn’t mean you should or that it comes free – loss of project momentum has risks.
For instance, let’s say your team is working on a project that will implement a new technology and this project has a hard deadline – such as the start of tax season or Valentine ’s Day. For a variety of good reasons, let’s say you deprioritize this effort and drop other more important things into the team’s sprints for a month, knowing that given the team’s point velocity, you’ve got some buffer you can use now for some opportunity costs later. However, now the team isn’t thinking about this new technology, so that will require a little bit of a cost to pick back up. But even more insidious is this is new technology that the team hasn’t operationalized yet – they don’t know what they don’t know, which you always find out in production. So now you might be pushing up against a deadline with too much risk to go live.
My suggestion is to be diligent with focus and execution. All companies will constantly want change which is typical. Set an internal high bar so you can sort thru the noise and keep your focus and attention on what’s most important.
Really great points, especially the note that ‘just because you can switch easily doesn’t mean you should’. There’s a lot of emphasis put on being about to pivot easily and quickly, and indeed, that is one of the major benefits to a more agile company.
However, one of the things that I’ve always remembered that helps to balance this out for me is the idea that we’re ‘strategically stable so that we can be tactically flexible’. Pivoting on small measures and areas to improve efficiency or get working code out the door is a great idea – you can and should make those small trade-offs everyday to make sure you’re putting working code in front of customers to get real-world feedback as quickly as possible.
The higher level vantage, however, has to be more stable. The goals, the vision, the overall strategy has to be a foundation that you build your flexible operation on. If you’re constantly changing your long term vision and strategy, you’re causing massive swings in momentum and direction, just as Sean indicates, and this all has a cost. Even above and beyond the production-level development cost, it saps morale and drive, it demotivates, and it makes leadership seem indecisive.
Strategically stable, in this case, means have a clear idea of the goal or vision, and communicating that clearly. Additionally, it means clearly communicating when AND WHY there are changes to that. And it means have a vision that’s high level enough that it doesn’t need to change every few months in order to stay current. If your vision doesn’t extend past the next product release, you’re not thinking big enough!
Having this kind of a foundation makes it easier for the people implementing the ideas to shift and change as necessary, but to feel like they’re doing it in alignment with achieving a goal. They feel less jerked around, they remain focused on achieving the larger goals, and ultimately, they’re more productive, which makes everyone more successful. Win-win-win, right?
So, thanks, Sean, for pointing this out and making that distinction. I’ll be taking your points forward with me into my new field.