Leader Spotlight: The components of a good feature brief, with Monique Piras

---

Monique Piras is the Senior Director of Product Management for Core Platform at Ironclad, a category-leading contract lifecycle management (CLM) software company. At Ironclad, Monique leads the company’s core platform team — spanning Google Cloud infrastructure, developer productivity, identity and access management, native integrations, APIs, third-party partner ecosystems, data platform, foundational services, and core UI/design systems.

Monique began her career as a software engineer and technical project manager at Mercent (now CommerceHub), later becoming a technical product manager at Amazon. She subsequently led product initiatives at Expedia and Microsoft, where she developed deep expertise in platform infrastructure, enterprise-scale product strategy, and customer-centric innovation. Prior to Ironclad, Monique served as a product leader at Qualtrics, where she drove the 0-to-1 build of the digital experience analytics platform.

In our conversation, Monique shares how she helped redesign the feature brief and product requirements template and quarterly planning process — ultimately creating a clearer, more collaborative, and efficient workflow. She also discusses the importance of level-setting across the organization, especially during large-scale horizontal projects.

---

Driving requirements and alignment across functions

Based on your experience, what are some of the most common misconceptions PMs have when engaging with engineers and designers?

PMs sometimes have a misconception that all requirements have to be big and that they have to drive them alone. Bring in your engineers and designers early. As a PM, it’s your responsibility to help drive the requirements and understand what we’re going to prioritize. It’s important to use strategy market signals and prioritization frameworks, and drive alignment on those frameworks so everyone’s bought in.

Once you have those key priorities to focus on, it’s also a PM’s responsibility to write the product brief. What are the problems that we’re trying to solve here? Who are the personas and the target audience? You need to include a market assessment in there and what competitors to consider. What are the pain points the customer needs to solve? What does success look like and how do we measure it? Designers are often experienced at research. You can leverage them to help with customer problem exploration. If there is a design component, what does the end-to-end user experience and flow look like?

Your team is there to help you think through that in the early stages, so you don’t do it in isolation. Same with technical architects — they may want to have input into the actual requirements or feature brief because there are scenarios they need to consider. Overall, people are more invested and buy into it if they’re involved earlier. At Ironclad, we do jam sessions with our CPO because she’s innovative and loves helping. We’re building for an exec persona, so her perspective is very helpful. That creates more richness and better collaboration.

On the flip side, there’s often confusion during the requirements stage around who gets down to the granular requirements. I believe it’s a partnership — the PM can lead with their first take of what they believe the requirements should be, but they should partner with other stakeholders around technical feasibility. Designers need to have input to consider the user experience for empty states, full end-to-end flows, how the new feature plays with the rest of the platform, accessibility for users, and for us specifically, we rope in QE to create test cases. Everyone should be jamming on that — a PM alone can’t come up with all of these considerations.

What are your best practices for maintaining effective communication with all these parties?

Start small when it comes to understanding exactly what you’re prioritizing and going through problem definition. Once you have that clarity, that’s when you pull back and assess. A good example is if another team is consuming the service that we’re building. Say we have to build a functionality to sync records from a third-party system. Those are the individuals. Then, when we get down into our detailed requirements and technical, high-level designs, we loop them in early since they’re experts in their area.

After that initial assessment, we see if there’s work for them to do. If not, we can provide status updates, but if they have work to do that we depend on, we set up a project kickoff and create corresponding Slack channels. That way, the team can constantly stay informed and engaged. We’ll also hold weekly syncs to talk about the project status, blockers, and more.

The importance of level-setting

Product teams are often made up of people with very different backgrounds. How do you think about the evolution of the PM role and best practices with this in mind?

We come from all different industries and experiences, and viewpoints. It’s so important to level-set for this reason, and I’m seeing this more often now in my current role. How do we work together and align? What are the scrum principles we need to follow? Who’s doing what? What does that end-to-end process look like? I created a product excellence playbook to help break everything down. It lays out all the feedback channels that inform the prioritization backlog that the product manager is synthesizing and feeding into the product backlog.

As we talk through the PM’s responsibilities in the future, I think the PM should be writing the user stories and acceptance criteria, as well as aligning with the triad leads on how to work across tools. PMs use all different types of product backlog tools, so should everyone be using the same one? How you get those user stories across is so important. Who’s breaking down those user stories, doing story pointing with the team, and tracking the work through Gantt charts?

Laying out all of this helps the whole triad operate more smoothly and efficiently. Then, there won’t be confusion over who’s doing what or any built-up resentment. Having that alignment, mutual respect for each other’s functions, and level setting is crucial. Of course, the triad is there to support one another, and each member can step into different areas of execution to help the team succeed. The key is to align and communicate when that support is needed.

As more specific roles in product, such as technical product managers, become more prominent, how does that play into the challenge of aligning the team?

It’s interesting — the technical product manager role used to be a middle layer between engineering and product, but now, that role is getting absorbed back into either one or the other. As a result, it’s a little more ambiguous about who drives that horizontal alignment, especially for very complex projects.

This is where the triad is so important to align. It’s a partnership, and we do this together. I like to make sure we clearly identify who is doing what between the team. We know that the PM is driving the why and engineering is driving the how, but we need to be proactive about working together if we want to be successful, especially for a horizontal initiative.

Re-imagining the feature brief process

Feature briefs have already come up a lot throughout our conversation. From your perspective, what types of data or information should be included in every feature brief?

At Ironclad, we have a feature brief template that we follow. I helped refine the pre-existing one after I joined because I wanted to modify it to separate the feature brief from detailed requirements. I’ve done this at previous companies as well, and it helps with that conversation. It takes a lot of pressure off having those granular details upfront, so that way, you have more time to work collaboratively with your triad. The product feature brief in the template is more like a summary of what we’re solving, who it’s for, and why it’s important now.

In the template, we also list observations, customer impacts, and what we’re hearing from customers themselves via interviews or support tickets. Are we losing deals because of this? We listen to customer conversations as well as leverage community channels. We document and aggregate those insights and the revenue associated with them. From there, we can make data-driven decisions on why we’re prioritizing specific things.

The other thing that we also include, which I especially love, is guiding principles. This helps our designers in particular, but also helps our engineering partners know the guardrails around the initiative. Whatever the product is, the guardrails help us all stay on the same page, even when we’re doing individual work. Lastly, we include success metrics so folks can reference them as the project moves forward.

You mentioned that your goal in modifying the template was to separate the brief from detailed product requirements. Can you explain the latter half of that process?

The detailed product requirements are listed separately within the document. For example, it’ll lay out when a user clicks on the delete button. What happens? Do they get a speed bump that says, “Are you sure you want to delete this?” What happens when they try to exit that module? How about when they confirm deletion? Or, if we’re writing about a dropdown filter, is it multi-select or single select? Can a user search in the dropdown filter? What are they filtering by? Is it an exact match? Those are the level of details that we should be getting to and feeding into the acceptance criteria.

From there, the engineering team will go off and architect it, and QEs will write test cases, etc. Too often, I’ve seen use cases get missed because teams didn’t have specific, detailed product requirements. They’ll build something a certain way and realize, “Oh no, we didn’t think about all these various scenarios.”

This all comes back to understanding your personas and how they use your product. That’s why that upfront discovery is so crucial. You need to understand how the existing product works as well, otherwise, you can accidentally put yourself in a tricky situation because you didn’t consider all the use cases and edge cases.

Are there any other common gaps that you often see in early-stage feature briefs? How do you coach your PMs to address those before involving other teams?

A common challenge is also understanding the persona they’re building for. Often, the use cases and narratives aren’t detailed enough. To get it more grounded and real, one of the things I did was incorporate a product narrative to describe how the product solves a problem or improves a situation for the user.

What is their role, and what do they do on a day-to-day basis? What problem and pain points do they have? How often do they log on to Ironclad? What is the reason? What does success look like for them? From there, we can understand how our product helps them and works in their daily lives. By writing the narratives out, the team can really get down to the details. It helps shape out requirements and what we’re going after.

Further, not validating with customers is often a big gap. That’s why in my feature brief, I have a user research section. It’s like a forcing function to have a conversation with the customer. We have to get evidence that this is solving a market need. This section helps our PMs because it asks them to summarize their findings and how they inform the requirements. Linking off to those research findings that help shape the requirements is so important.

Breaking out of working in isolation

How do you hold teams accountable to feature briefs without creating bottlenecks or excessive bureaucracy in the product pipeline? Can you share some best practices?

There are a couple of ways I do this. Our design team holds a design critique where they come together as a function to review designs, and I do the same thing with feature briefs. We get the leads together, along with their pods, to review them together alongside other PMs. It’s a learning experience for everyone involved, especially the reviewers. It’s great for the product team as well, because they’re not only learning about document writing and gathering feedback, but are hearing that other teams are building concurrently. We sometimes work in isolation across different functions, so this is always a great practice.

Also, everyone has different perspectives and experiences. They can use this time to insert their use cases or other considerations we need to think about. It’s a collaborative session, and I allow the PM team to decide which feature briefs they want this co-collaboration on.

As your teams scale, how do you evolve the role and depth of feature briefs?

Templates are templates — they’re starting points. Especially when it comes to horizontal and cross-team partnerships, we work on projects that touch a lot of surface area. We don’t always start with detailed user stories because the first step is to understand how the system works today — the current state or as-is experience. This requires mapping the end-to-end user journey and identifying where friction or inefficiencies exist.

From there, we break the broader surface area into logical segments or phases. Each phase becomes an opportunity to go deeper — collaborating with design and engineering to define what needs to change and why. Only after this discovery work do we translate findings into detailed product requirements and user stories.

We often run working sessions or ‘jams’ with key stakeholders to align on these phases, validate the as-is state, and co-create the future-state experience before jumping into execution. In this kind of horizontal, cross-functional work, it’s less about forcing a rigid framework upfront and more about sequencing the work in a way that drives clarity and momentum.

In general, it all starts with alignment and collaboration. We figure out what collaboration needs to look like throughout the project’s life and the various steps that we need to take. From there, we put that into a project plan and evolve it over time.