Product Operations Fundamentals: Part 1 The Framework (1 of 2)

There are two main pillars to an effective product operations strategy and there are aspects that can be deprioritized depending on company maturity and other organizational factors.

The first is a framework that captures important considerations related to marketing, product, design, and engineering and how the departmental work is interdependent. The second is a product-thinking organizational mindset. 

Now let me attempt to explain the significance of this through the lens of a design lead and based on my personal experience working at various startup and tech-based organizations. 

Typically, when starting in a new organization I'm given several weeks to gain organizational and product context including meet-and-greets, training, and familiarizing myself with the product(s). At some point, I will be given a PRD or ticket, typically in the form of a feature request that I'm able to start working on while continuing to gain further context. 

After being assigned the ticket one of the first things I want to do is assess what we collectively know about our users, the competition, and the market. Making informed design decisions is always preferable over uninformed design decisions and these initial findings help guide the problem-solving process. Depending on the ticket request I’ll start looking for any user persona, competitive analysis, or target market work that has been done. I might see if there is a user feedback repository and will want to understand why we are working on this feature now, what larger business objective this impacts, and how we will be measuring the success of our efforts. 

In an ideal product world, I could easily access this data to move towards a design solution as efficiently as possible. Instead, I end up on a wild goose chase for information. Competitive analysis? Check with the marketing director. Come to find out, she's waiting on a co-founder to send it to her. The co-founder? He’s not sure where it is but will send me a half-completed spreadsheet in the meantime. This continues with each bit of information Im looking to gather. The big problem here isn’t about me having to chase down information, I'm happy to do so. The more detrimental issue for the business is the lack of alignment on what we know as a team. The very thing that should be guiding our collective product decision-making process is being thrown away or can’t be found.

To be clear there is absolutely nothing wrong with early-stage startups running a million miles an hour leaving a trail of disorganized documentation in their wake as they pursue “more important things” like launching an MVP, landing a big client, or securing investors. Where this becomes an issue is when these same early-stage startups begin to scale and grow their product teams. With each new hire, the problem gets exponentially worse and each new hire's impact diminishes. If there is not a collective and up-to-date understanding of organizational learnings, goals, success metrics, and problem-solving methodologies, you don't have a properly functioning product team. Instead you have something resembling a disjointed assembly line that simply takes orders from the top - the kryptonite of agile. Eventually, you will be beat out by a competing product team in the marketplace that understands how to collectively and continually gain insights and deliver to their customers accordingly. 

As product leaders and founders, we should formulate a product organizational strategy that is both easy to implement and scalable over time. One that considers both the macro and micro, allowing us to collectively add our findings as we go, and that demonstrates how departmental work impacts product decisions and business outcomes. 

Let’s look at the importance of each departmental module within the framework. 

Marketing Module

Go-to-market efforts should be a significant driving force behind your entire product operations. A new product that has not taken into consideration a go-to-market strategy will almost certainly fail at achieving organizational goals. Other considerations that need to be made within the Marketing Module include competitive analysis, target market, and product differentiation work. Author Bruce Cleveland points out in his book Traversing the Traction Gap that he believes a primary success indicator for startups is their ability to define or redefine the category they compete in. 

Product Module

Within the Product Module, we want to create and document a product vision, business goals, and relative OKRs. Establishing a “collective logic” is important here and can be achieved with the combination of a defined feature prioritization methodology, consistent ticket structuring, and defined ticket types with use case examples. The importance of this defined logic within the Product Module can not be overstated. 

Design Module

I think of design and engineering modules as being more dependent on marketing and product modules than vice versa. Design and engineering should be leveraging product and marketing work and formulating solutions accordingly. Things to consider specifically in the Design Module are a design system that meets both user and your product team's needs at that moment in time. A consistent ready-for-handoff Figma file template that highlights exploration (design thinking) work leading to the proposed solution should be found in the Design Module. A user testing repository and updated user personas should also be included here.

Engineering Module

Engineers are the master builders within a product organization. The goal is to build iteratively while trying to avoid reconfigurations and tear-downs as much as possible (because those things are expensive and time-consuming). New features and products that make it into production should include some form of testing and learnings that can be gained. The Engineering Module should include architecture, data flows, technologies, and security considerations and should be built to scale over time toward the product team's ultimate vision.   

The descriptions of these modules form a broad-stroke product operations plan and surely don't include every detail. Remember, the purpose is to optimize your team’s ability to collectively discover and deliver while being aligned with top-level business goals. 

If your team is experiencing product organizational challenges and looking for detailed and accessible ProductOps frameworks that can be implemented within weeks, please send me an email at brock@commonlanguage.io 

Coming Soon Part 2: The Product Thinking Mindset