Product Profiles: Noah Sclar, Sr. Product Manager at CUES
Welcome to our new content series, “Product Profiles”.
Every few weeks, we’ll interview a product leader to learn how their organization runs product management, from planning their product roadmap to managing their sprints to collaborating with other teams.
Noah talked to us about his day-to-day work, how he’s leveled-up as a PM, why they run sprints on a two-week cadence, how they approach product integrations, and more.
You can read on to see what he shared!
Can you walk me through how you work with your CTO and engineers?
I meet with my CTO on a bi-weekly cadence to talk through our priorities and next steps in taking the company vision and translating it to the product. This can be ideating net-new features we need to build and speccing them out with design, identifying existing features we should update, pinpointing bugs that need to be addressed, and so on.
Following these conversations, I build out the tickets in Jira and go on to have several meetings with our engineers during the first few days of the sprint. Throughout these meetings, the engineers can tell me if anything is unclear, what else I can provide to support them, and if they have any feedback on my ideas. In some cases, they’ll provide ideas that I didn’t even think were possible, or suggest more efficient solutions to a given problem. All of this to say, these calls are super collaborative, and we see developer feedback as an essential part of executing sprints successfully.
Once the engineers feel enabled to execute their tasks and go on to work on them, I QA the deliverables from the previous sprint, and by the end of that week I push them to production. So, just to clarify, our sprints are two weeks long, but the improvements and net-new features that come out of them go live by the end of the following week.
What’s something you’ve done to level-up as a product manager?
The last thing I want to be is the messenger, where I’d basically tell engineers that they need to do a certain task because so-and-so stakeholder wants it done.
I want to come into my conversations with engineers on a somewhat-level playing field and actually add value to the conversations. With that in mind, I’ve taken some coding classes to learn the coding language we use.
This has allowed me to better understand any issues they run up against, give them feedback on how to execute certain tasks, and feel more confident when confirming that we need certain tasks to get done within the current sprint.
Just to give you a quick example, API integrations are critical to our product. Before engaging with Merge, it was critical that I understood the technical nuances of API calls and payloads from specific 3rd-party applications. In addition, it was important to understand how the data from these payloads mapped back to our database.
The coding classes I took not only helped me grasp all of this but also understand specific issues and how to address them, like the prospect of payloads overwhelming our servers.
How did you land on running two-week sprints?
A lot of it has to do with how our product works, and I’d imagine that the answer is similar for PMs at other companies.
Our product is mobile-dependent, so while our users can send money or messages to colleagues via our web-based application, the beneficiaries would receive and accept the payments or messages via our mobile app.
We’ve found that iPhones release updates less frequently than Androids (our application is available on both devices), and, given the cadence with the former, we ultimately found that it didn’t make sense to release updates every week. Two weeks was perfect; it ensured that the updates kept pace with our team’s speed of innovation and it lined up well with Apple’s release schedule.
What KPIs do you care about?
It’s hard to gather customer feedback organically. Reason being, while our platform is critical to users, it isn’t necessarily going to inspire 5-star reviews. I like to compare us to Venmo in this scenario: Their users know that the application is invaluable to their day-to-day life, but you’d be hard pressed to find someone who actually feels compelled to write a review on the app.
With that said, product usage is really my north star. I like to check how much money is moving through our platform as well as how many messages get sent every day and week-over-week. As long as usage per user goes up on average, I’m generally happy.
Product usage also influences the majority of our feature enhancement decisions. For example, as we gain user data on withdrawals by channel (e.g. Paypal), we’ll follow the user data and allow that to inform our decisions. This can lead to creating quick actions for users to access funds instantly, allowing users to bank rewards for fewer volumes of transactions, among other potential enhancements.
How have you approached building and maintaining product integrations?
We’ve always known that product integrations are extremely important for us.
And while there are several ways that integrations can benefit our product, the ability to integrate employee rosters successfully across our clients’ HRIS solutions is probably the most important use case. Without a seamless integration, our clients would be forced to manually remove and add employees to our application every day; and considering that our clients naturally experience a lot of employee turnover, this can quickly turn into a nightmare.
We ended up using Merge to build several HRIS integrations and built daily roster syncs with our product. This has also allowed us to easily and accurately determine the number of active users in an account at a given point in time—enabling us to update our subscriptions with ease.
Now the proof is in the pudding: The integrations we’ve built with Merge have helped us prevent customer churn and have gone a long way in improving the customer experience.
Want to learn more about Merge? You can schedule a demo with one of our integration experts to discover how our platform can help you integrate at scale.