Itzik Mitzmacher is the VP of Product at Teza, an AI-powered communications firm building tools that redefine how we interpret the world and connect with audiences. He holds degrees in information systems engineering and business administration, and brings over 15 years of experience leading products across a range of industries and organizations. Before joining Teza in early 2025, Itzik served as SVP of Product at Innovid, an AI-driven omnichannel advertising platform. There, he played a pivotal role in scaling its product suite and spearheading innovation in video advertising technology.
In our conversation, Itzik talks about how to avoid becoming a feature factory by shifting your product team’s focus from outputs to outcomes, and the frameworks he follows to do so, including OKRs, North Star metrics, and the GIST framework. He also shares success metrics that his team uses to measure meaningful customer impact. Finally, Itzik discusses how to prevent teams from falling into reactive and feature-focused behaviors by using retrospectives, postmortems, and quarterly reviews.
There are a few signs. The biggest red flag is when success is measured by output and not by outcome. If a team celebrates that they shipped 10 features this quarter, but they can’t articulate the value that those features brought to the business, that’s a problem. It’s shipping for shipping’s sake, which is not what we want to do.
Another sign is when there is no follow-up on impact. If the team launches something new and then immediately moves to the next item on the roadmap with little to no analysis on what the previous feature solved and what impact it had, that’s another red flag.
The team backlog is another clear indicator. If the backlog is a laundry list of feature requests coming from various stakeholders without a real context of what the problem is, or what the goal of that initiative is, that’s “feature factory” behavior; simply building something because someone asked for it without understanding its value.
The shift doesn’t happen overnight. It’s a gradual cultural change that you need to work hard to achieve. At a high level, you need to have a very clear goal-setting framework and establish good habits, especially during the planning phase.
One of the approaches that works well for me is the objectives and key results (OKRs) framework. OKRs re-frame the conversation from focusing on what we will do, which is an output, to what we want to achieve, which is an outcome. For example, instead of your team saying, “We’ll deliver feature X and feature Y this quarter,” encourage them to set a clear objective like, “We want to improve the user onboarding experience.” Then, you can set the key results, such as an increase in user retention from 20 percent to 30 percent. That way, when the team starts, they are aiming for a clear outcome.
Another framework I like is the North Star metric, which is a single metric that captures the core value of our product to the customers. Once the North Star is determined, the organization has a shared target. Everyone wants to do whatever they need to increase this metric. If a stakeholder proposes a new idea, the first question everyone asks is, “How will this impact the North Star metric?”
It’s a simple question, but it quickly reveals whether the idea is relevant or not. Because if you can’t answer that easily, then you probably have an issue; either the North Star metric isn’t defined correctly, or the idea is simply not relevant.
The North Star metric also encourages cross-functional alignment on the team. Everyone, whether they’re in marketing, sales, or service, will be able to understand how to measure success.
Another framework I like is GIST, which stands for goals, ideas, steps, and tasks. It breaks down the rigid roadmap and planning into layers. You first set high-level goals, then you establish a repository of ideas — that’s the I in “GIST.” Next, you plan for each idea, breaking it down into steps, which are the experiments that you’ll run in a short cycle. Finally, you define specific tasks for each step that you’ll eventually execute.
What I love about this approach is that it encourages continuous discovery and validation. Instead of committing to a year-long roadmap of features, we only commit to the goals.
Finally, in the day-to-day workflow, I use a template for a product requirements document (PRD) that emphasizes outcomes instead of outputs. The top sections of the template ask questions like “What is the problem?”, “What is the customer benefit?”, and “What are the success metrics?” This forces the PM to answer those things right up front.
I always encourage the team to start with the why and the who before the what. The PM needs to fall in love with the problem, not the solution. Whenever there’s an idea or an experiment they want to test, they need to frame the idea as a problem they want to solve and not as an output they want to achieve. The outcome needs to be clearly articulated.
I borrowed a technique from Amazon, which is to draft a fake press release about your new feature before beginning development. If my current company is considering developing a new analytics dashboard, we would ask a PM to write a short press release about the feature, which highlights customer benefits. This exercise forces the PM to focus on the customer outcome — in this case, it’s a reduced setup time — rather than the technicalities of the feature.
Another way I train my team is to implement the outcome-first PRD template I mentioned earlier. The template always starts with the success metrics and the customer problem that we’re trying to solve. Those are very quick and easy wins that you can implement without much burden, just by changing the form and the meeting agenda. By making this a standard, you’re essentially training everyone that there is no way that you are going to work on a feature without those core pieces.
With regards to cross-functional teams, it’s important to get everyone’s input whenever you scope something new. So when you develop a new initiative or a new feature, it’s not only about the PM sitting in a room and defining the requirements. Great ideas come from everyone, so we make scoping a team effort. Usually, whenever we want to kick off a big, new initiative, we might do a workshop and invite all relevant stakeholders. It could be UX researchers, designers, engineers, data teams, CS, and in some cases, even clients.
It’s usually something that the PM leads, but everyone is involved. And if the client is there, we start with the client. If we have recordings of customer calls, then that’s usually the starting point to understand what the pain point is and what the problem is that we want to solve. Then there is an open brainstorming session with everyone involved to come up with ideas.
With this approach, you get two things: diverse perspectives and a sense of joint ownership over the outcomes. The whole team invests in the solution.
Finally, when you scope a new initiative, you want to tie it to high-level goals. You need to train PMs to think in terms of business outcomes and constantly connect the dots to the company objectives. Usually, there is a traceability between the initiative and the OKR. If there is no easy way to answer which objective this specific initiative is tied to, then in most cases, it means that this initiative is probably not something your team needs to work on right now.
Defining the right success metrics is crucial. If you define the wrong metric, it can paint a false picture and drive you towards the wrong behaviors. You need to aim for metrics that reflect the change in the user behavior or business health, and of course, ensure you don’t have vanity metrics. The key question I usually ask is, “If this metric moves in the desired direction, does it mean we are delivering more value to the customer or the business?” And if I cannot honestly say yes, then it probably means that the metric is either misleading or too superficial.
I’ll give you an example. User engagement is something we measure at Teza. Everyone wants to measure user engagement, but there is a big difference between a superficial and a meaningful metric for user engagement. A superficial metric might be to count the number of sessions per user or the time spent in the app. But if the user spends a long time in the app, that might actually mean that they are confused and don’t know what to do. A more impact-oriented metric around user engagement could be to define task completion rate: Did the user accomplish what they came to do? This is not necessarily easily measured, but it’s a more outcome-driven approach.
Another example is that we stopped counting the number of features we’re releasing and instead introduced something new: feature adoption rate. A target might be to get at least 60% of the user base to use a new feature at least once within 30 days of launch. That is a replacement for measuring the number of features we’re releasing.
When you replace the feature count with an adoption or utilization metric, it sends a message throughout the company that an experiment is not done until it delivers value.
To keep a team sustainably outcome-driven is like maintaining good habits after a successful diet or exercise plan; it requires attention and reinforcement. The first technique I recommend is to bake outcomes into your rhythm and rituals. You need to implement them into regular team ceremonies and continuously reinforce them.
For retrospectives, we don’t just discuss what went well or what needs to be improved; we also reflect on impact. We ask questions like, “Did the sprint move the needle on our Q result? If not, why? What did we learn about the user outcome we are targeting?” This reminds everyone that delivering code without delivering value isn’t a true success.
Postmortems are similar. We don’t just analyze a failure; we analyze whether the experiment achieved the desired outcome or not. If we spent a couple of months building a new product and the adoption is low, we need to understand what went wrong. Was there something wrong with the assumptions we took? Did we truly understand the customer’s needs? How could we validate that earlier next time?
Another thing I like is storytelling and highlighting wins and failures. If a team running a lean experiment yields a big insight and significantly moves a metric, we ask them to present it in an all-hands meeting session, which not only gives them recognition but also serves as a reminder to others about the way we work.
This mindset isn’t just something that we’re doing as part of the product team. It also comes from leadership. If the CEO used to say in a company all-hands meeting to celebrate that we launched Y, then if we want to move from a feature factory to this other approach, we have to change the messaging. They can say, “Customer satisfaction improved by Y percent because we launched Y.” This might seem like a small thing, but it’s important because it allows us to emphasize how the organization works.
Lastly, which might be the most important thing, is to make sure that everyone, especially the product team, has a continual customer connection. If someone sits with a customer and hears them say something like, “I wish your product could do X, it would save me so much time,” this allows them to better understand customer needs and brainstorm potential solutions.
It’s these retrospectives, postmortems, reviews, and storytelling that work together to create a kind of immune system for the organization’s culture. Eventually, the payoff will be huge because teams will be more motivated, customers will see more value, and the business results will follow. That’s how the magic happens.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
One of the biggest changes to prototyping has been the rise of tools that leverage the power of AI to simplify the development process.
Espen Scheuer, Head of Product, Patient and Developer Experiences at NexHealth, shares how NexHealth structures its product organization.
Canva offers hundreds of thousands of free templates and 100+ million design assets to appeal to all different types of users.
Shayani Roy talks about balancing innovation with speed, thoughtfulness, and commitment to solving customer problems.
Learn more →
