For any enterprise software company or startup, the ultimate measure of success is how much money it makes for its investors. Money is the best surrogate we have for value a company delivers to the world - and by extension, the impact it has on the world.
For a product company like ours, its the product that delivers this value. Hence, the goal of product management is to build products & features that customers value & are willing to pay for. Our customers derive value when they use our products to address important design problems, but the journey starts much earlier, starting with how they discover our product, their perception of the product pricing, their experience during the sales process, and most importantly - their experience after they have bought the product.
On the other side, in order to be successful, product management works with designers & software developers in defining and sequencing what needs to be built to deliver value.
Development cycles are no longer a problem area
While the latter has received significant attention, and almost down to a science. Thanks in part to the rich literature on development, over the last year we have continued to drive down our time-to-production, which today stands at 5 days (now with much reduced variability since we moved away from Scrum & adopted Kanban). This means that any new feature that customers would value can be built & deployed in less than 5 days. A major contributor here has also been our focus on moving developers closer to customers via support rotations, frequent usability testing, and integration with engagement-tracking software like Totango which give us rich visibility into how the product is being used. We don't ship any new feature without tracking commensurate module/action in Totango.
Time to revenue as a metric
While for software development teams Time to production metric an objective works well, one of the metrics to track for product management becomes Time to Revenue, and minimizing this time requires significant focus in ensuring that information flows from the edges of the business to product management, and the other way around, as quickly as possible.
Now unlike software developers and designers, their primary job is not to respond to product management's needs. Many constituents of the business interact with the world, and their primary job ranges from marketing & selling the product to helping customers adopt the product in greater numbers, thereby making money for the business. This makes flow of information inherently frictional, and the business must organize to make this as frictionless as possible
In order to solve this problem, most companies have product managers who go & speak with customers, sales teams, marketing teams, and customer success teams to learn about the world outside, and in turn helps them do their job better by arming them with valuable information. This makes product managers an important constituent. This also implies that there is reduced burden on other business teams in deeply understanding the needs of product management.
Decentralizing product management
At Sefaira, we have taken a different approach. We believe that organizing our teams to maximize our surface area that interacts with the world, product management needs to be distributed at the edges, and product management responsibilities need to be embedded with the edges of the business. In order to be successful here, we need to ensure the teams are always aware of key things we are trying to learn from the world, and in turn be able to push this information to product management. Conversely, they need to be the voice of product management.
Product management responsibilities need to be embedded in the DNA of all business functions. This reduces product management's responsibility to organizing incoming incoming information, look for the most compelling hypothesis and test them by devoting maximum development fire power at these hypothesis. In turn, product management leans on the business to evaluate the outcomes.
What does this mean for other functions?
For different stakeholders, I will outline key areas where they need to think like a product manager in addition to their core responsibilities.
Sales rep
- When a prospect ask about functionality that the product doesn't have, learn if the prospect would value the functionality they are seeking. If yes, what problem would they solve with it?
- When a prospect is unwilling to buy at proposed price, learn how much they are willing to pay for the product
- When a prospect is unwilling to buy, learn what problems the product would need to solve for them for them to value it
In turn, they should be equipped to talk about the kinds of problems we are looking to solve in the upcoming months, and learn if prospects value solutions to those problems. A false or a positive signal both unlock different kinds of investments based on product management's judgment.
Marketing
- Build new content and drive awareness based on what the product team is building
- Create and spread the word on success stories
- Build a compelling set of use cases for the product
Customer success
- Learn of blockers to product adoption
- Recruit users for usability testing and user interviews
- Learn how latest features are being used & provide insight to product management
Once these expectations are clear, the organization needs to be instrumented such that information can flow freely. We intend to rely on a combination of Asana, Slack, & Totango to stay aligned here.
The benefits of such organization are immense. Due to inherent decentralization of product management, this can shorten cycle times significantly, and scale well as the business & product footprint grows without the need for hiring additional product managers, or impacting cycle times. This keeps our business responsive to customer needs and allows us to bridge the gap between problems and solutions rapidly.
No comments:
Post a Comment