Bring Producore into your organization
The Adopting Producore Roadmap shows how an organization brings Producore into the way it develops and maintains software Products. Most organizations should not try to change everything at once. Start small and strategically by choosing one part of the organization as the first adoption area. Leaders understand what the adoption changes and back it. People taking on Producore responsibilities prepare for the work they will do. The organization establishes Producore in that first area, learns from what happens there, strengthens the adoption, and expands from there in deliberate steps, using what it learns to guide each expansion.
Need the Producore overview first? Start with What Is Producore?
How adoption develops
Prepare leaders and participants
Leaders need to understand what Producore changes, why the organization is adopting it, and which responsibilities participants will take on.
Learn more ↓Choose where to begin
Producore is meant to become part of how the organization develops and maintains software Products. The organization still needs to decide where to begin.
Learn more ↓Put Producore to work
In the first area, Capability Managers work with the people who hold the relevant Product, domain, specialist, and Engineering knowledge.
Learn more ↓Learn from the work, strengthen, and expand
Some conditions only become visible when Producore is operating inside the organization.
Learn more ↓Prepare leaders and participants
Leaders need to understand what Producore changes, why the organization is adopting it, which responsibilities participants will take on, and where executive decisions or support may be needed. The people taking on Producore responsibilities need to understand those responsibilities and develop the skills required to perform them.
When one responsibility or skill depends on another, establish that prerequisite first. Preparation continues as people take on additional responsibilities and Producore expands through the organization.
Choose where to begin
Producore is meant to become part of how the organization develops and maintains software Products. The organization still needs to decide where to begin.
Choose a strategic place to start. Keep the first area focused enough that the organization can support the adoption closely and learn from what happens there. Establish Producore in that area, strengthen the adoption as needed, and then expand in deliberate steps, using what the organization learns to guide each expansion.
Executive leaders also need to understand and back the adoption from the start. They need to understand why the structural controls are being introduced, protect the time and authority required to use them, and help resolve organizational obstacles when priorities, processes, or other pressures pull against the adoption.
Put Producore to work
As the organization develops and maintains software Products in the first area, Capability Managers work with the people who hold the relevant Product knowledge, business and domain expertise, specialist knowledge, and Engineering knowledge. Capability Managers do not take over Product, Engineering, or specialist decisions. The people who own those decisions continue making them.
For each Capability involved in that work, its Capability Manager works with those people to develop and maintain the knowledge needed to manage that Capability over time. Together, the Capability Manager and the relevant contributors make explicit what the Capability must make possible and how it must behave under the relevant conditions. The Capability Manager maintains the resulting knowledge in the Product Knowledge Base, including the decisions that shaped that Behavior, why those decisions were made, the dependencies and constraints that matter, and any questions that remain unresolved. That knowledge is updated as the Product changes.
Before implementation of a Product change begins, the people responsible for the relevant Product requirements collaborate with Engineering to mature those requirements. They make the expected Behavior, important conditions, and underlying Product decisions clear enough that the people doing the work share the same understanding of what is required. Engineering then designs and implements the change, retaining authority over technical design and implementation.
When implementation reveals something that changes what the Product can or should do, Engineering brings that discovery back to the people who hold the relevant Product authority. They decide what the Product should do. The Capability Manager records the resulting decision and rationale in the Product Knowledge Base so the maintained Product knowledge reflects what was learned. That knowledge is then available to guide later Product decisions and future changes.
Learn from the work, strengthen, and expand
Some conditions only become visible when Producore is operating inside the organization. A person who owns an important decision may be difficult to reach when that decision is needed. A new responsibility may require more practice or support. A planning process may push implementation to begin before the Product requirements are ready. An important decision may still be left in a meeting or ticket instead of becoming part of the maintained Product knowledge.
The organization responds to what it finds. That may mean changing a process, improving access to decision-makers, adding support, extending preparation, or addressing another condition that prevents Producore from operating as intended.
Once Producore is operating dependably in the first area, the organization can keep strengthening internal ownership there while also extending Producore into other Products, Capabilities, or parts of the organization. Each expansion gives the organization another opportunity to learn and strengthen the adoption before expanding further. Different areas can progress at different speeds and use different levels of expert support.
How Producore works with what you already have
Where the organization already has a skill, practice, or function that performs a required job, keep using it. Preserve the Product-relevant knowledge and decisions that come from that work in the Product Knowledge Base. Adoption should use existing ability instead of duplicating it under a Producore label.
People in Product discovery and design, business and domain roles, Engineering, Security, Legal, Operations, Finance, and other disciplines continue doing their work and making the decisions that belong to them. Their work may change what the Product needs to do, place constraints on it, or provide knowledge that later decisions depend on. When that happens, the relevant Product knowledge, decisions, context, and rationale are preserved in the Product Knowledge Base.
Backlogs, boards, plans, schedules, and other work-management mechanisms continue coordinating work. The underlying Product knowledge is maintained in the Product Knowledge Base, where it remains available after the current ticket, release, or initiative is over.
Some existing practices may exist mainly because Product meaning has to be carried from one place to another, duplicated across tools, synchronized between copies, or reconstructed after it was lost. Once that meaning has a maintained home in the Product Knowledge Base, the organization can decide whether those practices should be simplified, changed, or removed. Practices that serve another useful purpose remain for that purpose.
Support for adopting Producore
Producore experts can help leaders choose where to begin, prepare participants, coach people as they use Producore, diagnose problems, and help the organization respond to what adoption reveals. When necessary, experts can also temporarily perform difficult functions while people inside the organization develop the experience and judgment needed to take them on.
Durable adoption does not require experts to disappear. It does mean that the organization can perform the responsibilities it intends to own without depending indefinitely on a particular expert to perform those responsibilities for it.
A Producore Program is designed to produce a specific result. Depending on the Program, it may use preparation, training, coaching, guided application, support, and evaluation to help participants achieve and demonstrate that result.
Engineering Excellence Roadmap
Specialized Roadmaps show how related skills and practices can be developed in a deliberate order when later abilities depend on earlier ones. The Engineering Excellence Roadmap is the current specialized Roadmap for Engineering development and can support the Engineering side of broader Producore adoption.
Explore the Engineering Excellence RoadmapPrograms, specialized Roadmaps, and expert support each help with particular parts of adoption. This roadmap shows how those parts fit into the larger path: establishing Producore in the organization, learning from its use, strengthening the organization's ability to operate it, and expanding it over time.
Plan your Producore adoption
If you are considering Producore for your organization, tell us what you are trying to change and how your organization develops software today. We can help you choose where to begin, identify the preparation and support that first adoption will need, and plan how Producore can grow from there.
Talk with Producore