How to Structure Software Product Management and Why it is Important?

Product management (specifically, software product management) is a cursed domain of work, where every company, even every individual, has a different approach and understanding. The software has been on the earth’s face for almost 75 years (depends on from which point you start to count) and the very first commercial software for 66 years; it has evolved into a sellable asset. At this point, the software product managers come into the picture to shape the software to be a product. Ironically, software product management’s role, responsibilities, and methodologies are still fuzzy and interpreted in a very broad spectrum.

I am using “software product manager” instead of “product manager” because software product management dramatically diverts from the traditional product management of the other domains, based on the expectations of the role. The other industries still use their own (and mostly well) definition of product management, which clearly describes the product manager’s role and responsibility. But the expectations in the software industry are much more higher.

Software Product Managers (SPMs) are expected to know almost everything; the customer, the technology, the market, the competition, and the future. They need to know the customer very well to understand their requirements and translate them into the techno mumbo-jumbo to communicate with the R&D.

A software product manager must understand and decide if an idea can convert to an economic value (i.e., money). They need to assess if developing a feature is technically possible, if it is doable by the company, and if it is doable, is it feasible or not. Software product managers must know about pricing, licensing, contracting, product positioning. And while dealing with these, all of a sudden, they should be able to turn their head 180 degrees and dig into the details of the newest technologies and make decisions that will affect the product’s success. In some cases, they need to discuss the database schemas or the API parameters with the developers, and move to the next meeting and decide with the graphic designers the color palette of the brochures to be used in the next exhibition.

Since the Renaissance is well over, and it is impossible to find know-it-all genius masters around, it is shocking how the software industry could not find a way or a formula to produce good software product managers. Software product management lacks a well-defined curriculum. Yes, it is possible to find some courses (especially for being a Product Owner in agile methodologies), but these courses do not give enough tools to the software product manager to survive in the wild.

Worse, even the most basic things are not defined: What is the difference between a good requirement set and a bad one? What are the ‘must-have’s of requirements, and how much detail should they give? What are the rules for establishing a roadmap? What should a functional specification include, who should write it, the software product manager or the development team? How can the features defined in the functional specification be converted to licensable items, in which terms, and sold? Where do the user interfaces and the user experiences fit in this overall picture? And where does the software product manager’s responsibility start (and end, if it ever ends) in this flow?

I’ve been struggling with these questions in my career, with the feeling of doing things wrong or incomplete. But, nobody seemed to be bothered with not having a clear product management checklist, not having well-defined tasks and steps. The communication problem between software product management and development was inevitable and given. These problems were just the nature of the work. The industry had multiple development and architectural models, but their corresponding product management methodology was void. It is absurd to see there isn’t any agreed format of requirements, where there are aggressive suggestions for the variable names and the indentations.

As of now, software product management is performed neither as science nor as art. Of course, there are examples of good performances, especially tightly related to the company’s culture and way of doing business. But most of the time, a guideline is missing. So it is really hard to keep up with the demand in the software product management tasks, in an industry growing 8% every year.

I have tried to collect and describe in a formal-ish way the methodology that I have been following — and due to the absence of it, developing — for the software product management. Being very far from a complete methodology, at least it puts some guidelines as a start. This methodology; Structured Software Product Management; depends on the following assumptions:

• Software Product Manager is the sole owner and the decision-maker of the product. Every product is an individual P&L center, and SPM is the responsible manager for that center.
• Inter department relations are vendor-customer basis. SPM is the client of the R&D, Pre-sales and Sales are the clients of SPM.
• SPM doesn’t need to do everything by herself/himself. For example, the document writers can prepare the product collaterals; software architect can prepare the high-level design. But for every artifact within the SPM’s scope, SPM is the approver, responsible and final owner.
• SPM is also responsible for ensuring everyone in the company has the same understanding of the product, its targets, strengths, and weaknesses.

Since Software Product Management is covering a broad area, I will try to describe the guidelines that I follow in separate posts. I plan to cover the following areas:

• Requirement Specification and Requirement Analysis
• Defining the Product Feature Set
• Roadmap
• Product Analysis and Design
• Product Information & Collaterals
• Reference Architecture, Benchmarking & Dimensioning
• Business Model & Licensing & Pricing
• Product Training

On top of these, the idea building, market info gathering are essential step 0 activities. There are well-defined ways of doing these, and I will try to mention them at the end, with the pros and cons that I faced.

I hope these guidelines can be a good starting point for the software product managers who try to find better ways for product management.