Anthony Enzor-DeMeo is Chief Product Officer at Roofstock, a real estate investment platform. He began his career in product at Dealer.com, a digital marketing solution for the automotive industry, before moving to Wayfair, where he spent more than seven years working on everything from B2B, B2C, supply chain platforms, and supplier experience. Anthony completed his MBA at the MIT Sloan School of Management and then took on product leadership roles at Better before joining Roofstock.
In our conversation, Anthony talks about how structuring objectives and key results (OKRs) looks different at every company, depending on factors like stage, maturity, company size, and culture. He discusses the role of accountability in hitting goals and how, to some companies, accountability may not necessarily be punitive. Anthony also shares advice to aspiring product executives explaining that “rigidity is the enemy” when it comes to moving through your product management career.
My style is definitely led by a customer mindset. Some companies operate by maximizing revenue only, which is obviously important for for-profit businesses, however organizations also need to keep in mind who they are selling to. I think it’s the product manager’s mindset of putting the customer first is of paramount importance. A product manager first needs to ask themselves, “What is my company selling? Is it a physical good or a piece of software?” The role of product and how you structure OKRs can be vastly different between the two.
The second point of differentiation is usually the type of customer. With B2C, you’re dealing with millions of people in the ecommerce realm. With B2B, it can actually be as little as a few dozen. On the B2C lens, product leaders should be looking at averages, trends, churn, and data. B2B product leaders need to be looking much more at bespoke solutions that are tailored to gaps in the market, where you’re trying to be competitive with other SaaS offerings.
Regardless of B2B versus B2C, at the end of the day, I would expect the product manager to put the customer first.
Yes. There are many ways to structure technology organizations. It’s pretty tightly coupled to OKRs. I tell people that once your company reaches a certain precipice of size, suddenly there’s a ton of inertia, shared goals, everyone’s accountable, and no one’s accountable. You need to figure out how this all works. And companies slow down. There are two keys to having OKRs at larger-scale companies: technical independence and organizational design.
Technical independence is related to whether you’re still dealing with a monolith or if you embrace API-first methodology — that old Amazon quote that every team should be building APIs within their sprint teams. Those types of things unlock teams to operate independently and not rely on each other. When it comes to organizational construct, if you have technical independence, you can structure teams that are solely accountable to an objective.
Yes and no. I think a smaller company could choose to have a team focused on returns, checkout, or other aspects of the product’s process. What I’ve seen to be the natural progression of companies is that when you’re smaller, your goal is either growth or revenue. You’re making trade-offs to prioritize those two things. That usually comes at the expense of scalability, and companies incur technical debt.
If I made a quick decision to satisfy this customer need and multiply that by 1,000 times over the two-year life of a Series A business, I suddenly have all these things I need to clean up. You raise another round, VC firms expect you to do TAM-adjacent work, and now I need to have multiple personas, but I have all this technical debt. It’s totally possible to do that. I think the natural flow of companies is to move quickly, and then at a certain point, they’re at an inflection point of needing to make other decisions.
Not completely. The first thing a company needs to do, regardless of stage or size, is have a North Star. What’s the statement of our business in a sentence? It’s important that employees can remember that also. Secondly, it’s important to establish the three things we care about this year. Those usually come from the leadership team. Those are what I generally call tenets or company goals.
After that, there’s a myriad of frameworks that can or cannot work. There are RACI matrices that decide who does what, there’s V2MOM of Salesforce, etc. What’s important is a combination of top-down and bottom-up frameworks. When it’s solely one or the other, I’ve seen organizations fail. A top-down organization will say, “Why do I exist? Here are the guardrails.” A bottom-up organization would say, “I’m the expert in this space, and this is how I am going to contribute to those goals.” That creates objectives.
How you structure objectives and key results is much more important than the naming. For instance, company philosophy on this stuff is pretty important. Some companies would say, “If you have a key result, you need to hit it. You want to make $100 million, hit $100 million.” Other companies would say, “That’s a goal, but getting 70 or 80 percent of the way there is still fine by me.” This comes down to the company culture as well as frameworks. If you have a culture of failing fast, learning, moving, and being able to talk about losses, you’ll tend to be more successful at software development.
Yeah. I think product managers who have worked at bigger companies are trained in pretty regimented styles. So whether it’s an Amazonian six-pager or PR/FAQs, there are set documents that people generally get trained in. Sometimes, if product managers from bigger companies go to smaller companies, they’re met with what I call organizational intolerance for overhead. It’s like, “This doesn’t fit with the pace I move. That doesn’t work here.”
Half of a product person or CPO’s job is to ask, “What’s my playbook? What’s the culture of this business? And what is the level and frequency and style of check-ins that make sense?” It’s a lot of trial and error. It’s the product leader’s job to test and iterate accordingly. I think the primary difference when it comes to a CPO is understanding where you have to push the business. Why were you hired and what do you need to push the business to? For example, do you need to push it toward more accountability and monthly check-ins?
Some of this is culture-dependent. Generally speaking, how you report on the success is also important. Let’s say you’ve written an objective of $100 million in revenue at the end of the year within this business. That’s the KR of the OKR. And let’s say you’re trailing behind. I worked at companies where, once a month, you get up on a podium, pull up the spreadsheet, and say, “I’m 60 percent toward this goal. Here’s what’s going well and here’s what’s going wrong from a rigidity standpoint.” More advanced companies tie OKRs to forecasting, so it becomes very clear that this is a stretch or not a stretch.
At Roofstock, we do that very well. We know exactly what we need, so then we also know what would be a stretch. If you hit the stretch, that becomes the gravy on top. Not every company has a culture like that. I still lean back on the fail-fast methodology for businesses. Ultimately, having any accountability for what you do is good. Companies and people sometimes make the mistake of thinking that accountability is not necessarily punitive. It can be, but that has implications on culture and OKRs.
Yeah. Let’s say a company’s done a good job at a vision statement and at laying out three focus areas for the year. It’s part of my job to say to every team, “How do you relate to that?” Some teams don’t relate to the focus as much. It’s not that they’re not important, they just may not be the focus for that year. Those drive other conversations, which is usually resource allocation. If I have these three focus areas, and you’re not one of them but you have 20 percent of my engineering resources, that might be problematic. How frequently do you adjust? That relies on how frequently companies plan. Personally, I try to not do any of those resource shifts more than once or twice a year.
I’ve been in the housing and real estate industry for a few years now, and it’s no surprise from a market standpoint that during COVID, the mortgage industry went through a lot and interest rates rose. Mortgage companies and real estate businesses had to recalibrate quite quickly. That leads to staffing and outsourcing decisions and focusing on the things that are most important to keep the business functioning. That has happened to a lot of tech businesses this year as well.
I’m not getting into any specific one, but what I would say is that those macro trends generally drive immediate precipice changes. CPOs who are inflexible to macro conditions are usually people who fail. Roofstock has done a good job scrutinizing OKRs, and in my opinion, it’s the CPO’s job to scrutinize technical investments.
The challenge is that, as a business scales, how someone relates to the key result sometimes becomes less clear. That is where the process is important. Salesforce is very famous for how they cascade down goals. I believe the spirit of OKRs is generally always appropriate, mostly because you need some check and balance of, “What am I trying to do and am I hitting it?” Whether you’re a Microsoft or a Series A business, that’s a good practice to be in. I also think there’s this caveat of how OKRs relate to software development. Not every company is in software development, but there are a few things that are generally always true in that space.
You’re iterating and testing. Some companies do that daily or weekly, and some companies do that quarterly or bi-yearly When you do that, it’s not an exact science — you’re testing it but you launch toward the expectations that you hoped for. Whether you’re a sprint team part of a 50,000-person company or a 200-person company, you have to know, “What’s the thing I signed up for when I launched it? What was the result I was expecting? And did it actually have the outcome I want?”
A way to track that is OKRs, and there are different ways to track that. The spirit of tracking iterative software development is always appropriate, but the rigidity of OKR is hyper-fluid based on the business.
First, feedback is a gift. If someone cares enough to give it to you, you should care enough to listen. When you stop hearing feedback, that might be problematic. If people stop giving you advice, you should probably check on that. I was taught that lesson by a manager very early on in my career.
Second, product management does not have a dedicated college degree. Some schools are starting to offer classes or concentrations in it, but as such, it looks different based on company and size. If someone’s goal is ultimately to be a product leader, it’s pretty important that they’ve worked on all sorts of products. Learn really good processes at big tech companies but also learn the pain of sales cycles and revenue at Series A businesses.
Over time, you’re going to develop a playbook. And if you’re really ambitious, swap industries when you swap companies. Because then, down the road, you’ll have this deep playbook and bench of information. When you get into a leadership role, you’re piecing all those things together for what works for a given business. Rigidity is the enemy here, so being as fluid as possible will help people in their careers.
I did so much recruiting at past companies. The first thing I would say is that there are growing tracks of product management. There are consumer-based product managers who work on frontend flows and, for example, on mobile customer experience. But then there are product managers that manage backend systems. Companies make the mistake of having one competency model and one set of criteria for the two. It is rare in my opinion, for people to excel at all things. Determine who this product management work is aimed at.
Then, there’s what I would call this “fork in the road of recruiting” of what I would be looking for. For frontend PMs, I’d be looking for intense customer empathy, optimization of customer flows, and examples of work I can speak to and look at. On the backend, I’d be looking for much more technical acumen and being very good at internal stakeholder management because chances are, they’ll be managing a platform or backend team that serves a lot of other teams.
In some ways they’re similar, and in other ways, they’re not. You can reduce the cycles of recruiting a lot if you hone in on the persona of your product manager.
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.
Payton White talks about how to create a consistent experience by maintaining the feeling that the brand wants to evoke in the customer.
A product specialist (PS) is a person with extensive knowledge about a specific product or product management-related responsibility.
Ben Hackett discusses the balance of revenue and core cultural values and how ruthless prioritization comes from first-principles thinking.
A project baseline acts as a reference point so you can compare project progress against your intended plan.
Learn more →
