In Reality, It Is Templates That Make a Difference
Introduction
From formulating a strategy to prioritizing features, templates help product managers overcome routine work challenges efficiently and promptly.
This review explains why work templates are imperative for product management.
The Backdrop that Brought Us Here
Many software development companies adopted the Agile Manifesto (promoted as the theory) and Scrum (promoted as the practice) combination as a way to build software.
Using 1960s lightweight software development principles (minimal, simplified, iterative), the Agile Manifesto, introduced in 2001, was designed to alleviate the monetary and contractual implications of modifying the feature set while custom software development is ongoing.
The second of the four Values (declared preferences) of the Agile Manifesto is “Working software over comprehensive documentation”.
This value emphasizes the Agile Manifesto’s authors’ belief that writing computer code takes precedence over documenting current or future work.
It is noted that software development contractors working on a custom development project are paid by milestones, not by the volume of documentation they prepare.
Also, the type of laborious and comprehensive design and requirements documentation used by the authors of the Agile Manifesto during the 1990s, some thirty years ago, is different from the more efficient design and requirements documentation practices used today.
The authors of the Agile Manifesto proclaim that direct conversations are the alternative to documentation, noted in the sixth principle of the Agile Manifesto: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
This sixth principle is broad and sweeping, with no stipulations concerning the information’s volume, complexity, abstractness, maintainability, and revision.
Applying the Agile Manifesto’s second value and sixth principle verbatim may quickly get a software development project into trouble.
Experience demonstrates that one could not accomplish much or build anything, especially software, by relying solely on high-level rhetoric in the form of values and a mindset.
Values and mindset are sorts of compasses, but they are insufficient alone.
Over-interpretation and misuse of Agile Manifesto’s second value and sixth principle have marginalized and even invalidated documenting information in software development.
Consequently, at companies that implemented Agile/Scrum, established software development documentation practices were categorically derided and replaced with a single general repository, the Scrum Product Backlog, and with colorful post-it sticky notes.
The Scrum Guide’s authors’ aversion to documents was apparently so great that they even went further to rebrand documents as Artifacts.
All this should have been relegated to and contained in product development, but it spilled over into business and product management.
Due to multiple skewed reasons, product management was drawn into the fray — thus impacting documentation in product management.
Technology product management comprises extremely well-ordered and well-disciplined processes and tasks.
There is little chance or sense of condensing the product management domain into a single repository or spreading pertinent product information on multiple sticky notes. Do so, and you quickly lose focus and context on the different levels of information in product management and delivery.
Technology product management requires layered, organized, flexible, and reusable documentation.
It’s Been Done Before
Best Practices are ways of performing business activities that have proven successful over time, and these practices can be somewhat reliably replicated elsewhere.
For the most part, best practices are supported by a consensus that they are the efficient and correct way of doing something.
Often, best practices become a de-facto standard to produce desired outcomes.
At the task level, typical product management best practices include the likes of roadmaps, product positioning, use cases, requirements management, market planning, etc.
Don’t Reinvent the Wheel
A Template is a guide, a pattern to follow to accomplish a task or produce something.
Template documents representing best practices help avoid the “reinvent the wheel” syndrome. In this markedly flawed situation, effort and time are unnecessarily expended to discover something true and tested that already exists.
Template documents in themselves provide immense advantages. They are reusable, repeatable, consistent, and their unified appearance projects professionalism.
Overall, template documents simplify tasks, provide progressive structure and guidance, prevent errors of omission, generate focus, help integrate newcomers, enable knowledge sharing, and save time and money.
Properly designed and built templates work well. However, not everything can be put in a template.
Furthermore, improperly using a template by strictly adhering to it can be restrictive and stifle creative thinking.
Not customizing a template when required or dogmatic over-reliance on templates eliminates task and process improvements.
The prevalent fear with templates is that they could become entrenched, which is problematic if they are deemed rigid, laborious, overly-detailed, plain flawed, or outdated.
Remember, completing a template is not the objective.
A template is a tool, a step-by-step path that leads you to produce a deliverable, be it a decision or organized information.
In reality, templates offer more advantages than disadvantages, but you need to know how to work with templates and when to use and customize them.
Product management templates, in particular, are highly productive as they allow product managers to focus on content (what to write) and not the method (how to write).
Product Management Templates
When a product management template is good, everything falls into place, and the benefits to the company, employees, and customers are enormous.
Many product management templates circulating the internet have been drawn to facilitate product management tasks.
Yet, product management templates are only as good as the theory they attempt to represent.
If the theory the product management template is based on lacks credibility or can be proven inconsistent, then that product management template lacks any practical significance.
In PMTK, the Product Manager is a highly strategic role responsible for managing the market problem that the product solves.
The PMTK Product Manager is a market expert who seeks potentially profitable market problems and describes them to product developers.
Therefore and according to Blackblot PMTK Methodology™, there really aren’t many core templates in product management, only three:
- Business Case — Defining a business rationale for building a product.
- MRD — Describing personas and market problems to the product development team.
- Market Plan — Guiding the delivery to market by leveraging the skills of marketing and sales.
The Business Case, Market Requirements Document (MRD), and Market Plan constitute the PMTK Core Documents.
PMTK Core Documents are the backbone of the entire product management process and can be used to create spin-off templates and documents for different audiences, purposes, and emphasis.
Summary
Practical product management templates are inspired by and embody a solid product management theory.
Designing an effective product management template is challenging, to say the least.
Integrating core product management templates into a company’s operations, minding the existing work culture and product nuances, will allow any organization to leverage some or most of the benefits described in this review.