Drew Doman is VP of Product at Apptegy, an education administration software that helps K–12 leaders build a strong digital brand. He started his career in consulting at EY before transitioning to a commercial finance and strategy role at The Mill, digital technology and advertising agency. From there, Drew joined the product team at Numerator, where he was later named Director of Product Management. Before his current position at Apptegy, he served as Senior Director of Product at Attain.
In our conversation, Drew talks about leveraging tenets in product management rather than strictly relying on processes. He also discusses the importance of being data-driven rather than data-dependent, i.e., trusting your gut and using your product instincts.
Apptegy is a communication platform for K–12 school districts. Our mission is to help school districts promote their brand. We give them tools for website and mobile app creation, for example, as well as a two-way communication platform to connect to the community. This also allows teachers and staff to communicate directly with students’ parents and guardians.
We’ve seen an increase in competition, particularly post-pandemic, within districts for both students and teachers. Giving those districts the opportunity to speak to the community about their brand, messages, and stories is hugely beneficial to achieving some of their challenges.
We have an alert product designed for when a school system needs to send urgent messages to all of the guardians within their district. They can use this product to quickly send out messages, such as, “Hey, there’s a fire drill today,” and push reminders as needed. These communications aren’t just in the form of text messages — they also can be delivered via email, phone call, text-to-voice, etc., and can be translated into different languages as well.
We have different communication tools for a variety of applications. We know school districts need a variety of channels and options to communicate different messages. Some are more urgent than others, and therefore, depending on how they need to distribute that content, they choose which of our tools to use.
For example, in addition to districts being able to share their general brand story, we enable them to send targeted, hyper-focused communications for specific items. These differ greatly by school and district. There’s a live feed on most of the websites we build that shows the most important updates for the community. That’s a really good balance of general news stories and school pride, like showing off the football or cross country teams’ recent achievements, and districts can tweak them to their specific needs.
My main product experience started in my time at The Mill and developed further at Numerator. I started in a product strategy role and quickly jumped into product management. As I continued to take on more of a leadership role at Numerator, I had to learn how to turn off the IC switch and trust my team to fulfill that role.
What I took away from that experience — and brought to later roles at Attain and Apptegy — was how to build the right frameworks for the team to be successful while not being prescriptive. Because as the team scales, that approach does not scale with it. You can’t have a bigger team and be everywhere all at once.
One of my mentors at The Mill had a great ethos that I’ve tried to adopt — “The job of a really successful manager is creating the conditions for the team to do the best work of their careers.” That’s something I’ve really tried to bring with me. If I can create the frameworks, the conditions, and the process (if needed) to enable the team to be really successful, I’ll be successful as a manager.
One thing was learning to slow down a bit. As an individual contributor, you feel like you’re running really quickly. I found it helpful to slow down and think, What is the mission? What is the vision? What framework are we using?
Slowing down to speed up was something I realized would make the team truly successful. Don’t be the IC who’s just running the race — pay attention to how you create the vision for the team. Where are you going and why are you going there? How do you get there? What are some of the things you need to believe and agree on and align as a team to get there?
I started to see that toward the end of my time at Numerator and quickly brought it to Attain. Now, at Apptegy, I’m really focused on setting that groundwork sooner rather than later with the team. With this approach, as the team and business scale, you have that foundation you can build on.
I’ve found that there is a lot of work that a product manager does outside of a process. An organization certainly needs processes, but having tenets gives product managers frameworks to use when maybe a process doesn’t exist or when they don’t want to over-design one.
For example, during my time at Attain, we moved very quickly as a startup. There were some processes, but I learned that because we were constantly changing, rather than over-designing the processes, I needed to instead think about how we approach problems. How do we think about problems as more of an ethos?
From there, I started to jot down the tenets that we believed in, regardless of process, strategy, or vision. Candidly, I took a lot of inspiration from things I’d read before. One tenet is that my job as the manager is to create conditions for the team to do their best work. If you’ve read No Rules Rules from Reed Hastings, the founder of Netflix, it talks about how we’re a team, not a family. As a manager, you need to have the best players on the field. You need to perform. Our job within business is to do our best, win new deals, and solve client problems. To do that, we need really high performance.
I’m inspired by Intercom’s “ship fast, ship early, ship often” ethos, and I believe that the product design and engineering group is the heartbeat of an organization. We’re constantly releasing new features and updating the product, and that pushes the lifeblood to sales and customer success to give them tools to go to market. If we take that heartbeat metaphor seriously, then it informs us to release frequently and keep moving fast. That’s a tenet that then can be translated into actions that support it.
Even when there are a ton of processes, it’s rare that they will fulfill 100 percent of the PM role. For example, at Apptegy, we’ve rolled out a new quarterly roadmapping process. We’re laying the groundwork for distinct processes within that for running product, engineering, and design teams. Those processes are important and we rely on them heavily, but tenets are a nice addition.
Tenets help make cultural changes in that they inform the team about how I think and what the culture should be. When I talk about how product and engineering are the heartbeat of the organization, that translates into me telling the team, “I want you to feel confident and empowered because we play such a pivotal role within that organization.” Tenets are complementary to process, but they’re also foundational to building a product culture from a new leader.
Yes. There’s a lot of content out there about being founder-led and the idea of having small teams. One tenet I believe in talks about how, if you give small teams a problem and a mission, there’s a lot that they can go and accomplish. Some people think this means larger organizations can’t thrive the same way, but big organizations absolutely do have a place and can thrive. This tenet is more about how to empower smaller subsets of teams with a specific mission and goal.
At Apptegy, we give each of our team members a very specific objective. This initial objective isn’t hyper-specific like “increase users by this much,” it’s more of a tenet to get started. From there, I ask each PM to think about how they want to measure that tenet. What do you think is going to be important to achieve that goal? The tenet is broad — it’s more of an objective. Each team member can then determine the best approach to measuring success, and we can collaborate on that and check in to ensure we’re making progress.
Sure. In product teams, you often hear that it’s important to make data-driven decisions. While I agree with that, there’s a missing piece there — product managers also have really strong gut feelings. They know what good design looks like and they know how to truly understand client problems. There’s a qualitative aspect to product management that is lost when you only emphasize data-driven decisions. Of course, you should absolutely use data as much as you possibly can, but you shouldn’t be hamstrung by feeling that you don’t have enough data to make a decision.
As a result, one overarching tenet we’ve been rolling out across the team is being data-driven, but not data-dependent. In other words, this means: trust your gut and use your product instincts. Call these areas out. It’s our job to push the product and the experience forward to fulfill customer problems. You can’t just avoid a decision because you don’t have any data. So, create data for the future, but move things forward and use your instincts too.
That’s where it’s very important to understand magnitude. What’s a super important problem to one client is a secondary or a tertiary problem to another. So, how do we take that to our roadmap and think about priorities? Within a given week of talking to clients, I’m probably speaking about two to three major different issues that they face. Regularly connecting with clients also helps product managers understand the array of issues their customers see regularly. As we think about our roadmap, we need to determine how to allocate resources to address some of those problems.
When a PM is with a client, the client’s issue can feel monumental. When the team comes out of a client call, they often want to immediately break down a wall and fix the problem for the client. That’s inherently a good thing, but sometimes we need to take a pause and say, “OK, what does this mean for the broader landscape? Does this correlate to other problems we’re hearing? Can we solve it in combination with other problems or is this a one-off issue?”
We meet as a product team every two weeks to discuss all the feedback that we’ve heard over that time. First and foremost, that helps us triangulate. Maybe we’ve all heard the same problem three different ways, and maybe only one person heard it. We put our heads together to say, “How important is that problem? Should we go solve it? Do we need to maybe put this on the back burner?”
For me, this is incredibly helpful to find out what the team is hearing. Also, the team gets to come together with all of the different products or features they’re working on and see how one problem can be solved in each of their individual components. That meeting has been a really interesting center point as we take the qualitative feedback. On top of that, we also ask “What’s your one big metric of the week?” Going back to the data-driven but not data-dependent tenet, we do both the qualitative and quantitative data in one meeting so we can discuss it together.
I can speak to this specifically from my time at Attain. My role was building the B2B software product from zero to one. As a lead, I would often demo the product. When you do that, you’re becoming a user and one of the best sources of feedback. Sometimes, you walk out of a demo and say, “Oh my gosh, that didn’t work the way I wanted it to.” Or, if you think about your product and the concept of explaining all the product decisions to a client, that frame of reference helps you think about why you’re prioritizing specific features or why you’re making certain trade-offs.
That demoing experience and frame of reference has really helped me, particularly in my time at Attain when we were building a product from zero to one, and now at Apptegy. It’s a great way to ensure I fully understand the products, and I encourage all product teams to make it part of their workflow.
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.
Want to get sent new PM Leadership Spotlights when they come out?
“Disagree and commit” is a management principle that encourages team members to voice their opinions during the decision-making process.
By strategically combining products, you can offer greater value, increase average order profit, and stand out in a competitive market.
Alex Guernon talks about how she promotes a data-centric culture, including leading by example and giving PMs an effective measurement system.
Value has many forms outside of the exchange of money for products/services. It can be in the form of saving time, increasing revenue, etc.
Learn more →
