In part 4, I discussed processes, and talked about loosely-coupled and tightly-coupled processes. The reason I wanted to introduce those is because when I talk about understanding the Information Supply Chain and defining key Product Management tasks, it is in the context of supporting loosely and tightly coupled processes.
First, let’s define “Supply Chain”
A coordinated system of organizations, people, activities, information and resources involved in moving a product or service in physical or virtual manner from supplier to customer.
This is roughly what Wikipedia says at the beginning of it’s page on the topic. The page needs work, but I like the definition. Note the terms “coordinated”, “people”, “activities” and of course “information”. A supply chain can be a complex entity, and certainly in the physical world, it involves moving physical goods (raw materials, parts, finished products) from place to place, to those who need it, as they need it (just-in-time delivery).
In the software world, and particularly in the context of the software development process, the focus is on delivering high quality information to those who need it as (or before) they need it. One nice thing about information is that there are no inventory or warehouse costs for storing a document that is delivered early. Along with time, information quality is also important. A good requirements document delivered on time is much better than a poor document delivered early.
If you take a step back and look at the product development process, it is fundamentally about information flow and optimizing that flow. Deliver requirements late or poor requirements on time, and extra work must be done to accommodate for that. If requirements are not clear and precise, it can impact the amount of testing that must be done as the implementation of those unclear requirements may be sub-optimal.
Beyond the actual development process, if the requirements aren’t clear or, if they don’t correctly address market needs, then marketing and sales have to do extra work to achieve their goals. I’m not saying that everything is the result of faulty requirements, but simply illustrating the downstream impact of a single deliverable — the PRD. The same is true for every other information transaction that occurs. If the communication is not clear, or delivered in a “language” or with content unsuitable for the target audience, friction ensues.
We’re all familiar with the famous “tire swing” cartoon, which very succinctly illustrates this point.
(click to enlarge)
The software development process is complex, risky and full of unknowns. It’s really not like building a house, for example, where structural strengths of the materials are well known, the design is well understood, the land around it is suitable, and it’s very unlikely that every year, the ground it’s built on changes consistency. In general, it’s rare that the assumptions that were made in building the house are no longer valid. This is what happens to houses when that occurs.
(click to enlarge)
When this happens to a house, it’s time to get a new house. When this happens in the software world, people call support and expect someone to fix it! But I digress. 🙂
Given the risks in the product development process, it is important to understand who needs what information, when they need it, and for what purpose. One can then identify what role each team, including product management, plays in this information supply chain, and what outputs are needed. I wrote about this topic a bit in a previous post, but its worth repeating here as it is critical to getting down to the definitions of deliverables that are the ultimate goal of this exercise.
If one were to look at all stages of the product development process, and identify all the parties (internal and external) that were involved at each stage, and map the intensity of their activities during those stages, you’d end up with a diagram that looks something like (but not necessarily like) this.
(click to enlarge)
This is a very simple heat map showing (on a scale from 1 to 3), the level of intensity of involvement of each group (shown on the left hand side) during each stage in the development process, from research, through development and out into launch etc.
Looking at the heat map, it’s clear that most of the intensity — and thus activity — is on the right hand side, i.e. the latter stages of product development, launch and release. The majority of the activity on the left hand side is in the top left, and related to product strategy, product management and product development teams.
So the question is, how do you optimally get from the left hand side to the right hand side? Or put another way, what information must flow between the groups, across the stages to ensure that the activities on the right hand side can be performed optimally?
To answer that for the whole diagram would not only be a huge task, but somewhat off topic. This blog is called On Product Management and not On What Everyone Should be Doing in my Software Company. 🙂
So, let’s look at the Product Management line only. Aside from making the task at hand simpler, this is also a good simplifying assumption for the whole supply chain process. The impact of product management on downstream activities is clear. So, if you can get that right, you’ve addressed a big part of the problem of optimizing downstream activities of other teams.
(click to enlarge)
The Product Management team is heavily involved from the early stages right through until almost the end where the intensity of involvement in a release drops off after the release is out in the market. There is still some activity of course, but in reality, when the product is launched, other teams such as Sales and Support are heavily focused on it, and Product Management focuses on upcoming releases.
The task now is to look at each stage, and list out the deliverables that must be created so that other teams can do their jobs in latter stages. Keep in mind that this is not a list of activities at a given stage, such as talking to customers, analyst meetings, win/loss analyses etc, but a list of deliverables that will be passed on down through to other teams so they can complete their work.
For example, a PRD may be the result of things like customer visits, analyst meetings and win/loss analyses, but the deliverable to the development team is what is important in the Information Supply Chain, because without it, they can’t do their job. How you created it is less important (to them). The assumption is, you are doing what you need to do to deliver the right requirements to them.
So, a bit of homework. 🙂
Think about your company, and what deliverables you need to provide to other teams at each stage of the development process. Also think about what others may need to deliver to you so you can get your job done as well.
In the next post, I’ll drill down even further into the specifics of deliverables at each stage and provide examples to help you define a Product Management Information Supply Chain for your company.
Saeed
The rest of the series
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)