Leader Spotlight: Developing intricate and impactful internal tools, with Dominique Neff

Dominique Neff is Director of Product Management at Starz, a premium entertainment destination for women and underrepresented audiences. A ballerina by training, she started her tech career as a freelance UX/UI designer before joining consulting firm Kin + Carta as a product owner.

In our conversation, Dominique talks about how she balances equity, urgency, and strategic impact with stakeholder requests. She also discusses how her teams maintain a flexible approach and her mantra that “if we've become rigid to certain goals or priorities, we've already lost.”

---

Building for niche internal tasks

You specialize in internal tooling at Starz. What are some of the unique challenges of building for internal users, and how have you adapted your overall product strategy accordingly?

I always joke that our internal users are like hostages, because we build the tools they have to use to get their jobs done. Unlike B2C companies that focus on churn, conversion, and other external metrics, our priority is making sure our tools actually help people accomplish their work. But jokes aside, that dynamic comes with a real sense of responsibility. Our users don’t have alternatives — they rely on us to get it right.

We’re often building for very niche workflows, so it’s not just about whether someone can complete a task. It’s also about whether they understand how that task fits into the bigger picture. Can they see what their teammates are working on? Do they know where their work fits in the overall process?

We ask ourselves questions like, “Do users know what they should be working on? Do they understand what others are doing? Is the tool flexible enough to handle edge cases, not just the happy path? Are we building features that improve quality of life?”

How do you advocate for internal tools and prioritize internal feature requests, especially in an environment where executive attention is limited and may be focused on customer-facing outcomes?

We try not to build for whoever yells the loudest. Even though we’re working on internal tools, we still need to think about the broader organizational impact of each feature. One of the things I love about our team is the trust we’ve built. Our executives assume we’re working on the right things, which gives us the freedom to make smart decisions with the people who actually use the tools.

That trust comes from being transparent. Even if we don’t have hard metrics, we always define the organizational benefit of a feature — at least with hypotheses or estimated impact. We also have a standardized intake process, so execs always know where to go if they want to understand what’s in flight.

Lately, we’ve been leaning into a more “show-and-tell” culture during roadmap meetings. We don’t just read out project statuses — we show what we’re building, explain what it does, and talk about what it means for users. We share consistent updates week over week, which helps stakeholders at a higher level really get a visceral sense of what we’re working on. It’s made those meetings more engaging and, honestly, more fun.

Regarding the intake process, is there a template that you leverage? How does that process work?

We start with a high-level intake template. We ask the requester to describe what they need, why they need it, what they’re trying to do, or what problem they’re facing.

We’ve been shifting the focus away from “here’s what I want you to build” and more toward “here’s the problem I’m trying to solve.” As a product team, we often have a broader view of the ecosystem, so the best solution might be different from what they originally imagined.

Depending on the request, we’ll then bring in a larger group of stakeholders to walk through the intake and see if it impacts other teams. That helps us catch dependencies early and make sure we’re solving the right problem in the right way.

Providing a framework for prioritization and roadmapping

How do you align your tooling roadmap with broader company goals when departments have different definitions of what is critical?

There's really no silver bullet here. We're not in the business of dictating priorities — instead, we aim for a balance between top-down and bottom-up goal setting. For internal tooling, our north stars are usually improving efficiency, reducing costs, or laying the groundwork for future initiatives.

Because internal tools are so interconnected, solving a problem in one area often has ripple effects for other teams. That’s why collaboration is key. We focus on getting the right people in the room to hash things out. Everyone brings different perspectives on what’s important and how to approach it, but generally, folks are great about working together once we provide a framework to guide the conversation.

I’m a big believer in putting pen to paper. When you give people something concrete to react to, it’s easier to say, “Hey, that’s not right” or “I really think this part is going to work for us” and move forward. There are lots of product strategies out there, but for us, it’s about creating space for discussion and iteration and empowering our people to use their instincts to get to the bottom of a problem and hash out solutions.

Could you share an example to highlight what types of solutions you work on in this way, and how they affect different people in the organization?

Sure — we’re currently working on a tool to manage metadata updates. After a show or movie airs, there are often changes to the metadata. Those updates start at the source, but they need to be processed, communicated downstream, and eventually shared with partners.

We’re building a single system of record to track and route those changes. The idea is to give employees the ability to decide whether or not to send a change, depending on the context. It’s a great example of how one tool can serve multiple teams — upstream and downstream — by giving everyone a shared source of truth.

Maintaining a flexible process

What's your approach to intake and triage when requests vastly exceed your team's capacity? How do you balance equity, urgency, and strategic impact?

As a product team, if we ever get too rigid about our roadmap, we've already lost. Our process is intentionally flexible because we expect things to change. That said, we’re always working within constraints — limited time, limited budget, and limited people.

When new requests come in, we try to objectively weigh the pros and cons with our stakeholders. We ask, “Is this truly a priority? Is it more important than what we’re already working on? What’s the tradeoff if we take this on? Alternatively, is there additional budget to support this?" If so, we can explore other levers — like bringing in contractors, buying a third-party solution, or partnering with another team.

What does user research look like when your users are internal? How do you adapt traditional UX methods to environments where people might be too busy or too close to give you unbiased input?

“Too busy” or “too close” is pretty much the norm. The methods we use are fairly standard, but the topics we explore are very specific to internal tooling. We tailor our approach depending on the questions we’re trying to answer — there’s no one-size-fits-all.

One of our biggest challenges is that our teams are lean, and we usually encounter two types of users. Those who are just thrilled we’re building anything for them are hesitant to be critical, and those who have a very specific vision of how the tool should work — down to the smallest detail — which doesn’t always scale beyond their team or role.

Every team works a little differently, so we’re constantly balancing user feedback with UX best practices, our internal design principles, and the need for consistency across the system.

Focusing on the goal and improving morale

What metrics do you believe matter most, and how do you ensure your team is not just measuring output, but actual operational improvement or behavioral change?

We always start by asking: What’s the goal of this initiative? What are we trying to achieve for the organization? At a high level, it usually comes down to one of three things — improving efficiency, reducing costs, or future-proofing a process for upcoming initiatives.

From there, we build hypotheses like, “We believe this will reduce time on task,” or “This should cut down on manual errors,” or “This will set us up to be able to deliver this new thing to users.” One of our go-to methods is mapping out a before-and-after workflow. We visualize the current process, highlight what we’re trying to deprecate, and show how the new tool or feature changes things. That gives us a clear picture of the impact — what was happening before and what is possible now. Plus, if my team can make one of these diagrams, it’s a great indication that they really understand the ins and outs of the process.

Is there an example you can share where you made a tooling improvement that had a really big impact on morale?

Absolutely. This is a great example of how simple can be better. We recently released a feature that lets users schedule package deliveries. Before, it was a time-based process — packages would automatically flow downstream once they hit a certain status. But because Starz produces original content, we’re very cautious about leaks. So teams would hold back packages by keeping them in the wrong status, even though they were technically ready to go.

That created two problems. Firstly, the metadata was inaccurate, which caused confusion. Secondly, if a release needed to happen on a holiday or weekend, someone had to log in on their day off to push it through.

With this new feature, teams can now schedule the release in advance. They can set a specific date for the package to flow out, and if the air date changes, the system automatically adjusts. It was a huge quality-of-life improvement. Teams were genuinely excited — they no longer had to work on holidays just to hit a deadline. That’s one of the best parts of working on internal tools. With consumer-facing products, you often only hear feedback when something goes wrong. But internally, we can see when something is working for them and has made an improvement to their work or work-life.