Tim Martin is Sr. Group Product Manager – Data & Applications at Driveway, a digital platform reimagining the car buying, selling, and service process. He began his career as a project manager at Rogue Valley Manor before transitioning to product management at Pacific Retirement Services, a company that owns and operates several Life Plan Communities. Tim then moved to Driveway, where he has managed multiple products, including sell, checkout, and revenue.
In our conversation, Tim talks about how he structures teams as they scale and transition through the various phases of being a startup. He discusses how he optimizes processes and KPIs for teams to fit their current working models. Tim also shares his approach to maintaining a strong culture as an organization changes so rapidly.
There’s a surprising amount of similarities. In the senior living industry, I worked for a company that owned and operated a life plan community — targeting people in their 50s and 60s who wanted to join and then age in place. One of the interesting similarities I didn’t think about when I transitioned into automotive was the sales lifecycle.
Joining a life plan community is a large purchase with a long move and sales timeline, similar to buying an expensive product like a car. In both industries, customers have long purchase cycles where they’re doing broad-ranging research and then diving deeper on a specific product, such as a particular car or community. They’re learning all the details of what that one offers and then going back out to say, “Do I like this category of product or do I want to find something else that more specifically has what I need?”
Another similarity is the importance of partnering with the marketing and operations departments. When you’re selling a product with a 6-12 month customer decision timeframe, you need to make sure that the touchpoints from the marketing team and what they’re selling translate to the actual ownership experience of the product.
It always starts with defining the product’s mission and vision at a high level and making sure that they can ladder down to the individual team so that they can have some ownership over what they build. It’s about being clear about where we’re trying to go from a strategic standpoint and then reviewing those short-term opportunities as they come in.
In my new role, I’m trying to balance where we want to take the larger product suite for internal applications with how we can save money on the things that exist right now. It’s always a trade-off, but going back to the larger mission and vision of the product helps the teams make those decisions on a case-by-case basis.
Things are very dynamic when you start at an organization of three people. When you have a meeting, the entire team is automatically included. The mission and vision of the organization don’t need to be documented or visible in the same way because everyone’s in all the meetings, so everyone understands. You know the context of why you’re doing something all the time.
When you expand, you need to construct that vision in a way that can cascade down to the organization. That way, individuals have ownership of their decisions and know that their decisions ladder up to the larger mission. So, much of it concerns context and how you document your reasons for doing things.
The larger idea is that people tend to have to wear many hats in the early stages — one person may be doing product, training, financials, etc., at the same time. The context becomes important to share, so that needs to be accessible. Also, people should understand why the business is going in a certain direction so that they can do their jobs more effectively.
One of the things I’ve realized about organizational structure is that it is a lot more of an art than a science. You need to understand so many different traits and try to take a finite number of people, money, resources, etc., and make sure you allocate them appropriately.
I tend to consider prior experience — what they have done in the past, what types of problems they have solved, and industry experience — and measure if those are required prerequisites for this role. Even in the automotive space, there are different sectors people can come from that work with the same dynamics, tech stacks, and skills as ours.
Ultimately, it’s about taking a ton of input about the people and the situation that the company is in, as well as where we want to go, and trying to create the best structure. Thinking about all those constraints, getting together with a core group of leaders that I trust, talking through the logic, and whiteboarding have helped me build well-structured teams in the past.
It’s tough. There’s no silver bullet or one-size-fits-all solution for it. It starts with hiring and making sure I’m getting people that align with the company values and the direction of the organization. Structuring the organization to manage team stress, being clear about the mission and vision, and strategically communicating change are all critical factors.
The most important thing is fostering real relationships with people on the team. That way, I understand how people in the organization perceive the larger organizational messaging, mission, vision, and communication. Getting feedback about whether or not those things are resonating is crucial. I also ensure that I deal with issues as they come up and be direct with them instead of letting them fester.
I believe the most important thing you can do as a leader is to spend time with people. When I onboard new employees, I tell them that our second 1:1 might seem strange. In that meeting, I ask them, “How can I be a better manager for you? How can I know when you’re struggling? How can I help you when you’re struggling? What do you like to do when you’ve done a good job? How do you celebrate wins? How do you like feedback? Do you like praise publicly? Do you prefer to be praised privately?”
I start by trying to get to know the new hire as a person, and then I spend a lot of time running through our product development life cycle. I explain how it works and how to be successful in it. Once they have a foundation of the process and understand the area, we spend time running through other materials. I make sure to be prescriptive about their first assignment. I want to ensure they use the tools they were trained on and get feedback on what they’re doing early and often. This way, they will know what success looks like in our organization, and they can get some wins.
Scaling processes has been one of the biggest challenges for me. I have not always been a process person and prefer to tailor approaches to the situation. As my roles have evolved, I’ve realized the importance of ensuring we all have a common vernacular and understanding of what success looks like, which all comes from the processes.
The companies I’ve seen be successful at having unified processes are the ones that invest in a department or area that owns and champions them. This could be a product operation vertical or a program vertical — a leader helping with training, providing tools to be successful in the process, and taking in feedback to adapt processes as the team grows.
Successfully scaling processes is also about making investments that pay dividends down the road. I recognize the need to invest in the process when I notice varying levels of success in the organization at doing a specific thing. Then, I can identify areas ripe for a process to be introduced.
Like most of what I have learned in my career, this example comes from shortcomings. Early in my career, I took on a new team and saw it was following different processes than the successful team I had recently led. We were moving closer to our quarterly planning exercise, so I wanted to guide the new team through the quarterly planning process to make sure their dependencies were mapped out and set up for success.
The failure came from not fully appreciating the importance of a common vernacular and standardized process during joint planning exercises. When we began the meetings, it became clear that teams were at different levels of preparedness. Some were well-prepared, with clear documentation of their needs, while others hadn’t had a chance to even review their projects.
The new teams felt stressed and unprepared. It was supposed to be a fun first attempt at a new process, but it turned out to be the opposite. The pivot that we made was to standardize what being “ready” for that exercise looked like. This way, everyone knew what must be done before the meetings began.
These metrics definitely evolve over time. One of the things that I’ve become a lot more fascinated with as our team has grown is the concept of a proxy metric. Each team that I’m working with may not have bodies of work that directly impact revenue, retention, or long-term growth. So, I focus on identifying metrics that these individual teams can influence and use these metrics to prove or disprove hypotheses that ladder up to the long-term goals.
However, these goals or metrics change over time. You might’ve identified a metric that is going to correlate to the organization’s KPIs and worked to influence it, but then realize that the correlation isn’t as strong as you thought. You then have to tweak it and refine it. That’s where our focus as an organization has shifted. We spend a lot more time talking about those metrics and refining them with our operations and marketing teams. We bring them to an advisory board that reviews bodies of work and asks questions about why we think these metrics will influence the larger organizational goals.
One of the best pieces of guidance I received about this was from a mentor. They explained how communication has multiple lives. The first life is when you’re presenting that message to the team. You need to think about the situations that a team is facing right then and there at that moment and what is relevant to their context.
The second life begins when the message is heard. Not everyone will be in that initial meeting, so it’s important to ensure that those there understand the message well enough to communicate it accurately to their peers.
The third and last life of a message is historical. New team members will join the company after you’ve left, and they will try to understand why certain decisions were made. Being able to reference those larger strategic messages from a historical perspective is vital to help people who are joining in and don’t have you to share the context.
The most powerful thing that anyone in product, specifically, can learn to do is to say no. Saying no allows you to say yes to other things. For me, it’s about helping the team understand that our yeses are meaningful, but they come at a cost — we can only say yes to certain things if we’re willing to say no to others.
When requests come in, even if they’re valid and well-intentioned, it’s crucial to evaluate them against the company’s mission and vision. If you don’t, you end up trying to serve a bunch of different customers, and you do that poorly, too.
The most important thing in this regard has been starting with a team meeting. We have a weekly meeting with a set structure. Even as a manager, IC-oriented tasks pop up that I have to do. I let my teams know, “Hey, these are the IC tasks that I have to get done this week, and here’s why I have to do them.” I also update them on the changes in the organization and the industry.
It’s also super important to provide the team with an opportunity to praise other people on the team. This boosts morale and is a great way to add positivity to the meeting.
With that said, the most important addition to that team meeting is what we’ve coined as the “monkey wrench”. This is an opportunity for people to bring in things that didn’t go well the previous week. It’s a space to safely bring it up and talk about what they learned from it. For me, as a leader, the monkey wrench is an opportunity to publicly address mistakes I’ve made in the past week. It lets people know that I am also learning to do things better.
Making sure there are regular touchpoints with these strategies has been a huge game changer. We have pretty tight standards on what needs to be completed based on the project or product we’re working on. As a leader, being strategic about my time allows me to best communicate and make sure that the organization is going where it needs to.
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.
A practical framework for product leaders to prioritize better, reduce noise, and focus teams on what matters most.
Explore how urban planning helps product managers think in systems, strengthen foundations, and build products that scale well.
Learn how product managers can move from output tracking to outcome-driven product management with metrics tied to user impact.
Learn how to spot PMF erosion early, diagnose the cause, and help your product recover before decline turns into panic.
Learn more →
