I started Grafted Management with the goal of having a broader impact on the technology community in Seattle and around the Pacific Northwest, then could be afforded by focusing down on one specific domain or company. By instead building a partner for companies, focusing on helping others build amazing software products and engaging digital experiences, I can apply my background and accumulated skills. I can share my knowledge with more folks across more projects and products. While there are quite a few consultancies and contract shops around the area that will step in and help you get your project or product architected and coded up, there aren’t many that understand product strategy and execution, and can step into your shoes at the product level – to help with product strategy, design, and tactical execution across the full product lifecycle.
This is pretty unfortunate.
We have seen an incredible arc of change in how we organize, build, deploy, and support our software products. We have optimized and decomposed how software developers do what they do, moving from long, insular development cycles to a general acceptance of short-cycle, iterative delivery, usually managed with Atlassian’s tools. We’ve optimized IT operations as well, with most companies getting out of the tactics of hosting and into the cloud, and instead investing their in-house talent into “DevOps”, allowing the whole thing to work together, from development and into the customer’s hands. Features can now flow into production with unprecedented speed.
But what is driving those features? How do we know they are the right ones? How do we know that we are thinking about the problem the right way? How do we handle conflict that can arise when stakeholders don’t agree? Heck, who are my stakeholders?
It is my experience that companies, particularly early to mid-stage companies, frequently neglect these aspects of product development. Sure, they may have an amazing architect and development team, and thanks to Microsoft, Amazon, Google, and others, they now have access to the most sophisticated hosting infrastructure imaginable, but they don’t have product management. Often product management happens by committee, with perhaps a lead developer, development manager, or engineering executive arguing with Sales about what the next release should have in it. It amazes me how organizations are willing to spend millions of dollars on software projects that have had no real up front, structured consideration as to business value, value-based feature prioritization, or even modest customer discovery.
Some of the more advanced, and strategically driven companies in the area have recognized this gap and have invested in product management, perhaps even introducing a Chief Product Officer role to their executive ranks. You will also find people roaming the halls of Microsoft and Amazon, Seattle’s largest technology providers, with the title of Product Manager, Director of Product Management, and the like. Unfortunately, Both of these companies do a very specific kind of product management, and probably not the kind of product management that is well aligned with what most companies actually need in the startup and mid-stage, from a practical product management perspective.
I was talking with a fellow Seattle based product leader recently, and he was sharing with me how seemingly unprepared Seattle product managers are. He felt that the supply of local product managers were not really prepared for their jobs. Either they were coming straight out of academia and simply didn’t know what they didn’t know, or they grew up with the large players in the region and have a really skewed view of what it means to be a product manager. Where the focus is more about the narrow feature or implementation details, and not so much about getting really close and empathetic with your customers. They can also be challenged with understanding what is going on across the product lifecycle, outside of the narrow, traditional PM world of gathering and managing requirements for a small set of capabilities.
They can struggle with understanding the big picture business value, and context. How does my product relate and contribute to the broader business? How do individual feature decisions impact business value? Can I deliver more value to the organization by prioritizing capabilities that help Sales advance more deals? Once my products are built, how are they going to be priced, marketed, and sold? What user experience attributes help to best support the metrics most important to the business?
These questions can only be answered when companies understand the need for product management, and start looking beyond the “product management by committee” approach. They also require product managers and product management practices that center on driving and delivering business value over other potential motivators. Product managers must take it upon themselves to learn, understand, and own the full lifecycle of their product across the business. Top to bottom, no excuses. For those organizations that have more narrowly focused product managers, the same applies at the feature set level. It is still all about understanding and driving business value.
More and more Seattle based technology companies are recognizing the need for sound product management as a driver of business value, and as a requirement for maximizing the value returned from their investment in software development projects. This is something that Silicon Valley companies of all sizes have understood for some time, and they have a rich product community as a result. I believe Seattle will get there as well, as those SV companies invade north, and as more companies experience the great benefit of embracing a formal, but pragmatic, approach to product management that puts customer value at the center.
