I think of myself to be a technical person. I like computers, simulators, code, things like that. And obviously interacting with people and helping them solve their technical problems using technology I know. However, it seems that one of the most impactful contributions made during my time at Intel was to start a meeting series. Maybe you can call it a process innovation.
I instituted the “Simics Quarterly Product and Feature Update”, SQPFU, a quarterly event where I would summarize recent product changes. Quarterly updates are a staple of the enterprise world – but these quarterlies in the way I ran them had surprisingly useful side effects for product management.
What is the QPFU Concept?
Dropping the “S”, let’s talk about the concept on its own. What is the concept of the QPFU, the Quarterly Product and Feature Update? As I see it and did it, it is about presenting a technical perspective on recent changes and updates to the product.
A key aspect is that a QPFU should only cover actual shipping product features. The users should be able to use anything mentioned immediately. Exceptions to this rule are major changes looming as part of the product planning – think major version updates, end-of-life of major features, switching supported hosts, or changing GUI applications. Giving users advance warning for such changes is a good idea. It might also be worth repeating such changes for a few quarters after they happen, as the pickup of new releases might be slow.
Information about recent success stories is not in scope – they are not something that a user can use. There are plenty of other quarterly updates where management can talk (brag) about successes and future corporate plans. The QPFU call is for technical people, by technical people. Keeping corporate and organizational aspects out the QPFU keeps it focused on the product and its users.
The Contents
Here is an outline of a typical SQPFU call as I did it:
In short:
- Start with a welcome providing the scope of the call and the product versions/releases covered by the call.
- Next, discuss extraordinary features or events, like the aforementioned upcoming major changes.
- User-facing features is a major section, covering command-line commands and GUI features. Both new features, and updates and improvements to existing features.
- For a product with a model/programmer interface as well as a user interface (such as Simics), the next section was for the modelers. Presenting updates to the product API, new SDKs, features related to particular programming language bindings, etc.
- Also probably unique to Simics, we present updates to generic and common target models and processor cores.
- Features in Tech Preview were put in its own section.
- Funny/sever bugs deserve their own section too.
- Finish up with information on current product training, new blog posts, internal stories, etc., to help users learn more about the product.
- Finally, it is always good to remind everyone about how support works, where the resources are located, etc.
Being Concrete
A good QPFU slide covers one distinct feature. It is more than just a summary of the release notes.
When talking about features, in particular GUI features and command-line commands, it is very helpful to provide concrete worked-through examples. For example, showing a new command or an old command with a new option, and what the results look like when used on a standard demo system.
For programming and API changes and features, it is a good idea to include simple code examples. It is often very hard to explain precisely what a new API call or library feature does without effectively painting code with natural language. Just showing the code makes it more concrete and easier to pick up.
Concrete examples with a problem-solution-code/command structure can also provide good fodder for machine-learning/large language models.
The QPFU call also provides an opportunity to explain why things were done. Coming from the core product management and development team, it makes sense to explain why features were added, modified, or removed. Such insights add value to users and helps them understand the overall philosophy of the product.
Admitting to Bugs
A sometimes-contentious inclusion is the section on “major bugs fixed”. In general, bug fixes are communicated through release notes and consumed by those who hit a particular issue. However, there are typically a few major issues solved each quarter that deserve to be included in the QPFU. These are issues that are high-impact or likely to have been encountered by many users. Telling everyone what happened and how it was solved builds trust; hiding bugs seems disingenuous if users will hit them anyways. Mentioning major bugs also means that users that hit a bug (since they are using an older version without the fixes) know how to fix it without bothering support or writing a duplicate bug report.
Bugs are also great for comical relief, so I made an effort to include at least some funny bug each quarter. Bugs where the product went completely off the rails for some dumb reason are the best bugs.
The Fine Print
The QPFU as I conceived it also included a section with standard information about how and where users would find support, upcoming trainings, and similar product-related info. Just to remind everyone where things are, and to help new users find the information.
Reuse in Other Context
The materials collected are also a great resource for other stakeholders in the company. Sales and external enabling teams can use them to explain what is new to customers. Management can use it as the basis for their regular reporting up the chain. Summaries are invariably useful, and technical well-designed summaries doubly so.
The Unexpected Product Management Effects
The QPFU is an obvious concept, basically providing an information flow from a product team to the product users. However, it turned out that instituting the QPFU had some internal benefits for the product and product management as well. The QPFU process found product inconsistencies and missing documentation. It forced the development of examples for new features.
The context is that the development team is fairly small but responsible for a rather large and sprawling product. Small groups are responsible for various technical areas, and they do not necessarily look at what other teams are doing. Having a geographically distributed team with a hybrid office policy and work-from-home engineers reduce the natural interaction between developers and also contribute to a certain drifting apart of the product.
Thus, when a developer needs to add a feature, like a command or even a variant of a command, it is easy to make a quick local call without considering the global context. In an ideal world, everything would be passed through product management and UX designers before implementation, but the world is not ideal.
Having one person go through all major changes in a quarter provides product management with a holistic view of the product. Developing the QPFU contents uncovers detailed design decisions that are inconsistent with the rest of the product, resulting in bug reports, feature requests/enhancement requests, and immediate fixes.
Another cross-product aspect is the interaction between tool features, modeling features, frameworks, and actual virtual platform models being built. It is not uncommon for a feature to be built assuming a certain test system, because that is how it was spontaneously tested. Preparing the QPFU might test features on a different system, revealing limitations. Another example would be that new modeling features lack support from inspection commands in the command-line interface. This might not be realized until someone tries to build a user-facing example involving the feature.
For a technical product manager striving to be a product expert, developing a QPFU is a fantastic way to learn.
Naming
To implement a QPFU, prefix “QPFU” with the name of your product. The result is hopefully a unique acronym that you can easily use to find and communicate. Nothing else will collide with it in the TLA namespace of your org, I can almost guarantee. It is an unwieldy mess of letters, but it is likely unique and quite hard to confuse with anything else.