Find Your Publisher
As developers, we are often separated from our users by multiple layers of management; line managers, project managers, and hierarchical organizations. Developers are rarely invited to requirements gathering meetings with the end users or stakeholders. The project manager will distill this list of user needs to a spreadsheet list, and then hand it off as a checklist to a developer to get it done.
Unfortunately, this is one of the worst mistakes a project can make. Imagine taking the architect out of the design process, asking a group of hospital patients and doctors how they want their hospital designed, and then handing it off to the construction crew to just get it done. The doctor wants an office on the 10th floor, and the patients want the hospital to be no taller than 3 floors. What happens to the product when direct contradictions arise?
Enter the Publisher
The Novel Project is an Agile project framework based on the language and process of creating and publishing a novel. Novel Projects recognize 3 key roles for completing a project. These roles work together to deliver a product that can be built and the audience will want. In an ideal world, these roles are filled by different specialized people. But since we don’t live in an ideal world, these can also be hats worn by fewer people or even a single individual. The important goal is to recognize which hat is being worn and to make sure each is represented in the project.
Editor; responsible for the process of completing the product ( Project Manager )
Writers; responsible for completing the product ( Developers )
Publisher; responsible for the value of the completed product ( Product Owner )
The Novel Project roles are shown above with their traditional names in parentheses. They are given different names from the traditional roles to highlight the differences of the roles from traditional project management, and also help bridge the gap between software project management and other project disciplines. In construction, the editor could be the superintendent who oversees the construction, the writers the construction crew, and the publisher would be the architect. No matter what the project, the responsibilities covered by these roles need to be addressed by someone.
The Editor and the Publisher are unique roles that should only be filled by one person at a time. The Publisher is the one person responsible for eliminating the contradictions of requirements, prioritizing needs, and bridging the gap between users and developers. When two people try to fill the Publisher role, there is the potential for contradictions between Publishers.
The Voice of the Customer
Developers make dozens of decisions every day that impact the final product in ways that most users wouldn’t even understand. They work on dynamic systems that are evolving with the work of other developers. Choices about what methods to use, or how to structure the data have big impacts on what features are easily supported, or what reports are more easily generated. Obviously the developer can’t pause the work to call a meeting with a dozen users to determine if this view should show table A or table B. That’s when the Publisher steps in as the voice of the customer.
The Publisher needs to have a clear understanding of what the market wants, what are the goals of the users and what is the value to the customer. They may lead the requirements gathering activities with the audience. The process of defining the final product should be done in discussion with the Editor and Writers, but the Publisher gets the final decision of what is in and what is not. The publisher could be the one bringing the initial idea to the project team. An adaptive organization should facilitate the process of ideation and encourage Publishers to step forward. A great way for any Publisher to start is by using the Product Synopsis method.
The Product Synopsis sets the stage for the current problem, provides a summary of what the solution is and who it’s for, and divides the project into at least 3 Minimal Marketable Features. This provides a document that concisely communicates the project goals. It can be shared with the potential audience as well as manager advocates to assist the Publisher in creating a consensus around the problem to be solved before starting the project.
Prioritize Outcomes
It is easy for a Publisher to become distracted with multiple great ideas that should be part of the final product. The key is focus. Focus on the Minimal Marketable Features described in the Product Synopsis. Once those are satisfactorily completed, then include additional ideas that improve the product.
A common failure point for projects is too many great ideas. A great idea should not distract the Publisher from the primary goals. When this happens, the end result is a fancy product that no one uses. The Publisher sets the priorities for the project team to complete. Sometimes this means saying no to great ideas, or at least later. The Publisher is responsible for the product meeting business goals, and decides what the final product will be.
The Publisher is the product owner, responsible for ensuring the final product meets business needs. They serve an important role in a project by defining project goals, representing the voice of the customer, and prioritizing features and ideas that will be added to the product. The Product Synopsis tool can help Publishers define a problem and establish project goals in a way that can be easily shared with stakeholders and management. The Publisher is often the unsung hero who turns a spreadsheet list of requirements into a coherent final product that people want to use. A product backlog isn’t a checklist, it needs an advocate who fits those pieces into the whole.
