Building a food office

The grocery office makes sense when it helps teams make better decisions faster, rather than adding another layer of approvals. Prior to launch, define its mandate, customers within the company, and problems that cannot be solved locally: shared data, portfolio conflicts, hiring, practice development, or team dependencies.

Prerequisites

Often, in large companies, products can grow “on their own,” out of the direct demands of stakeholders, the operational environment of the business, or repetition of competitors. Business dictates what to do and expects specific deadlines for specific tasks. In such cases, it is customary to say that the product develops according to the project approach.

As you grow up, the number of stakeholders and dependencies grows, and to cope with entropy, the approach can change to the design and product - iterations, streams, products will begin to make discavers, write documents on templates and even count some metrics.

This is a normal evolutionary path, especially for inhouse solutions that aim to meet specific needs of specific people. But sooner or later, the uncertainty will grow so much that the team will begin to ask existential questions - who we are, where and why.

At this point, we can talk about the need for **product transformation **, one way of implementing which is to build a **product office **.

Product transformation does not require a product office, but since we are talking about a mature project with a large team, it is appropriate to talk about the need for formalization.

See the difference between the design approach and the product approach

Product office

The grocery office is a feature that scales the product approach in a company.

We will not talk about product transformation and its goals, but we will talk about building a grocery office, which can become a point of reference for the transition to a product approach.

The product approach involves work in 3 directions:

• Practice - development of standards, processes, tools
  • methodology and artifacts
  • processes
  • role model and career framework
• Culture - working with people and developing roles
  • teaching
  • community
  • activities
• System - support and implementation of changes
  • rhythm
  • metrics

Practitioners

Practices are the framework of the product approach. It’s usually the first thing to appear in a grocery office, even if it’s not called that. Practitioners determine who will do what and how to achieve product goals.

A frequent mistake of product teams is practice for practice, often on the verge of a cargo cult. Creating practices cannot be an end in itself.

Artifacts don’t have to exist because they have to, they have to help teams communicate in a common language. Processes are not built to meet industry standards, they should help businesses achieve their goals systematically. The role model is not needed for skirts in slack, it is needed to determine the responsible.

Practices are needed to turn “heroism” into a reproducible system, the existence of which can greatly simplify the life of teams, answer many unasked questions and set a standard of quality, which will directly affect the results of the business.

Practices determine what the team’s Discovery process will look like.

Methodology and artifacts

Product methodology is a great area for debate.

Lean Startup, Agile, Design Thinking, Customer Development, Working Backwards, Continuous Discovery, Shape Up, OKR, etc. Is all of the above a methodology? There are also methods and frameworks - JTBD, North Star, Shape Up. And something can be both a methodology and a method, depending on the context. And some techniques that could be applied in one area could have migrated to another, like HADI from Growth likes to appear in Agile Discovery. Customer Development can be simplified to Customer Interview. Is that all, or is it just an opinion?

See Creating a Product Framework in 2 Minutes

Our job is not to define the methodology in which we work, but to explicitly formalize our approach to working for the team.

The market is large, everyone has different experience, some methodologies, although they have a well-established and common definition, but our goal is to guarantee a common approach.

In order for a methodology not to live in abstraction, it needs artifacts—small, practical templates to help the team reproduce the results, lead to the right questions, and help explain to each other the thought we want to express.

Artifacts should save time, not take away.

Artifacts, as well as methodologies, are full, choose them for your task, but there are those without which you can not imagine a single product team:

• Product strategy
• Roadmap
• BRD/URD/PRD
• One-pager
• Release notes

Each artifact must have a specific structure within it, determined by the process and context of the product.

Examples of questions we need to answer using methodology and artifacts:

• Who is the consumer of this document?
• What artifacts should be unified?
• In what format do we describe BRD?
• What is the release note format?
• How do we evaluate the market?
• How do we describe hypotheses?

Processes

The process is a consequence of the formalization of unplanned repetitive activities in planned.

An algorithm that has been formalized to simplify the lives of teams so they don’t “think again.”

Processes can be both internal and external - the process of product research, the process of inter-team communication, the recruitment process, the process of contacting counterparties, the process of creating a landing page, the process of requesting analytics, etc.

Like any artifact, the process should save time, but also protect the walker from errors. As a rule, a formalized process is a hard-fought general rules, the violation of which will cause pain to either party, or the offender himself risks shooting himself in the foot.

Processes should be formalized and transparent. The more transparent the process, the more people will use it. If it works well enough, it will eventually become a culture. But culture cannot be an excuse for not formalizing the process.

The success of the implementation of the created processes largely depends on their regularity and repeatability. If these parameters are at a low level - most likely, the process is not necessary here.

It is also important that the process should not be an obstacle for other teams. The “process, you have to fill out 50 form fields” situation is a sign of poor process design.

A process is also a kind of product that has users and performance metrics. Both the bank and the tax office have a process of interaction with the client, both need plus or minus the same data, but the former are asked to dictate only the phone number, and the latter give a 100-inflation form to fill out the application. Where’s the better process?

Role model and career framework

A role model is a formalized description of roles, responsibilities and decision-making authority.

Most often, the role model is presented in the form of RACI/DRI, and the description of individual roles is made in ** job descriptions**.

A role model is needed to:

• formalize expectations,
• clearly define areas of responsibility,
• speed up decision-making.

Frequent situation - role model or job descriptions are presented only on paper and are not used in practice. This may indicate that the documents are poorly compiled - superficially, not intelligible, or hidden somewhere far away, for ticks.

It is a good practice to draw up job descriptions so that they are used already at the recruitment stage as requirements for the candidate, and, in fact, are a guide to the work, as well as contain performance criteria. This will allow you to immediately hire the right people and align expectations from each other.

See. Example of job description

When drafting a role model, it is important to consider the current composition of the team, the availability of resources and the load – if you do not have business analysts, and the products on the canonical role model do not describe the requirements, then who will write them? If the requirements describe the products, who will do market research and hypotheses?

The introduction of a new role model is the transition from AS IS to TO BE. And this transition may not always be easy, especially if someone is used to working within certain limits. Find a way to make this transition with minimal resistance.

Another important element is the career framework.

A career framework is a description of the roles and levels in the company, expectations and competencies for each level by which employees are evaluated and planned for growth.

Your employees need to understand how they are being evaluated and what they can do to help the company get promoted. It’s an important part of motivation.

You should have a transparent grade system and transition criteria. This implies that you must have a competency matrix for all existing roles in your product office.

[See. Example of Competence Matrix (#)

Based on the competency matrix, you will be able to approach the objectivity of the evaluation of your employees, and, based on the results obtained, draw up an Individual Development Plan (IDP)**, which assumes transparent criteria for the promotion of an employee.

See. Example of IPR

Culture

Formalizing methodology, processes, and roles is easy. It’s hard to implement.

You will have to change the way people think, who are used to working in a certain way, while getting positive results.

You will encounter an incredible amount of verbal resistance, and all attempts to implement changes will result in things going back on track. This, in turn, will further reinforce the team’s minds about the meaninglessness of the ideas being imposed.

The key to solving this situation is regularity and patience.

Training

All innovations need to be taught, even if they are clear and obvious.

Working in a product team involves working with organized, intelligent, and productive people. On the one hand, it’s good, on the other hand, they won’t take it.

If they see that the new way you’re selling a task is doing the same thing, but they have to spend more mental resources, they won’t accept it because it’s counterproductive.

Your task is to seriously explain why we are doing all this and not only bring learning new practices closer to reality, but literally begin to shape this reality with their help. Ideally, you should set an example for the team and show how it should be.

The first time will not work, or you will be followed by a few. Some people will need months to switch to the new tracks, and some will refuse to accept the change. It’s a normal learning process.

Community

The best way to implement changes is to get the team to start implementing and developing the theme.

Create a group chat, hold Q&A meetings, let others make suggestions, ask questions and argue, and discuss changes among themselves.

Organizational behavior works in such a way that it is easier to accept change in a group than individually. The better you can ignite the team with ideas, the easier the period of adaptation will pass.

Activities

An important element of cultivating a food culture is organizing events for the team. These can be both formal and informal events - reports, book club, demos, conferences, reporting meetings of the head, mitapas.

If you have already organized a community, organizing events will help you develop it. Aerobatics - to make the community organize events, without your participation.

System system

To build a system means to put on stream all the changes made to achieve the goal.

To some extent, the success of building a system will reflect the result of the success or failure of building a product office.

At this stage, we must ensure that all our results are:

• predictable
• measurable
• accessible

Rhythms

Rhythms provide predictability and consistency. These are all regular meetings that form the production regime. Rhythms can be used to promote change and build culture, to involve the entire team of the unit and C-levels, to regularly review metrics, to align plans, etc.

Rhythms are easiest to set based on frequency, examples of rhythms:

• Weekly
  • Status Sync - status of current hypotheses/research, risks, metrics
• Biweekly
  • Sprint Planning - Prioritize for 2 weeks
  • Product Review / Demo – what delivered, what changed in metrics / behavior, feedback
  • How to improve process, quality, interaction, cycle speed
• Monthly
  • Roadmap Sync - Synchronization with roadmap, adjustment of plans
  • Tech/Product Health Review - Tech debt/quality/performance.
• Quarterly
  • OKR Review - Evaluation of quarterly results, update of targets and key results.
  • QBR - a team event with reports on the results of work
• Quarterly inter-team planning – Dependency synchronization with other teams/platform, plans arrangements

As with any other entity, rhythms should serve a specific purpose and not overload the team. The worst thing that can happen is that teams will attend these meetings not for the sake of meaning, but because they should.

Metrics.

The product approach implies that any changes should be measurable and affect metrics, product transformation and product office construction, in themselves, are also no exceptions.

Metrics should appear that reflect the impact of changes, whether they are process or financial metrics.

How many hypotheses have we tested before? What was the capacity of the teams? How much do we save on a job we no longer do? And others:

• adoption, the proportion of commands using templates/rhythms
• cycle time / lead time
• Discovery quality – the share of initiatives with an explicit hypothesis + metric

In addition to evaluating implemented changes, metrics can help in managing the grocery office – if the metric system is uniform for all streams, then it will be a great tool for correlating the performance of individual products.