Ryan Hinshaw is Head of Product, New Product at Lattice. He started his career as a product operations analyst at Zenefits before being promoted to product manager. In his last year there, he helped shift Zenefits’ business model to HR SaaS before joining Lattice. Ryan led the Reviews product team at Lattice before taking on leadership of teams developing new products for the ecosystem.
In our conversation, Ryan talks about how he helped implement a “startup inside of a startup” approach when developing an entirely new product at Lattice. He discusses the process of building the new product from the ground up, and how the initiative helped turn Lattice’s suite of products into a connected platform. Ryan also shares the importance of failing quickly and testing with small rollouts — two approaches that have helped his team build delightful product experiences.
This was a fun approach that we hadn’t previously taken at Lattice. The idea came about when we started thinking about going into the human resources information system (HRIS) space. This would include both payroll and time-tracking products and would move into supporting a broader set of employees.
We knew building an HRIS would be a massive endeavor that would take multiple years. We did a lot of upfront research around whether or not this would be something we wanted to pursue seriously. After we made the decision internally to move forward, we talked to over 50 customers and prospects. Next, we thought, “OK, how do we staff such a large initiative that is so different from our current core offering?”
To start, we needed to allow for a culture to do things that don’t scale. Millions of employees use Lattice’s product today. Our teams that work on existing products need to think about all of those users when they’re launching things. But when you’re trying to build something from zero to one, you’re just trying to get one customer. You want to do things that don’t scale, cut those corners, and be able to build that over time.
We gave the teams working on the HRIS products the autonomy for rapid experimentation and iteration. We told them that it’s OK to get things wrong for the sake of speed. It was important for us to give the air coverage to the team so they could learn from different things. Ultimately, we learned a huge amount of things while building this HRIS that we were able to apply to the broader platform. We tied a lot of the other products together through those learnings.
We went out and built a product advisory council with a handful of companies that were willing to work with us. Some of our earlier companies actually came from them too. We had two different cohorts in the initial build phases. They signed NDAs and we showed them early designs, mocks, etc. We learned as much as we could from them, including what their pain points were.
One really cool aspect of working here is that Lattice runs on Lattice. So, our own internal HR team collaborated closely with us. We engaged with them daily as we built this product — it was great to be customer number one of our own HRIS. We felt strongly about building a product that we could stand behind before making it available to other companies.
I think we did everything in our power to mitigate challenges. We worked on this new product initiative for about a year and a half, and did face some cultural differences among teams. One team was moving very fast and felt comfortable breaking things while the other team was worried about each of our millions of users. At some point, we knew we had to bring those two cultures back together.
There were definitely some bumps in the road, but when we set it up for success, it reported straight to the CEO. We provided constant updates to our senior team about what we were prioritizing, what was working, and what different touch points needed to happen within the Lattice ecosystem.
Previously, Lattice offered a set of products that didn’t necessarily talk to each other. We had products for reviews, engagement, and compensation, but if we made an update in one, it wouldn’t flow to the rest. With the introduction of the HRIS, all of our products became able to talk to each other and propagate updates across the system. This project wasn’t just about developing an HRIS — it was turning ourselves into a truly connected platform.
When we took the “startup inside of a startup” approach we made the decision to not take away resources from what was already going well. We really tried to limit the impact of this new initiative to successful products. There were a few people who came over that seeded the initial pieces of the team to make sure that our culture was there, but the majority of the team was made up of external hires.
I am always drawn to the biggest challenges and fires within a company. When I was approached to lead the HRIS initiative, I was inspired by the difficulty of the challenge. Previously, I built out Lattice’s reviews product. I helped take it from its early days where it worked well for 50-person companies to now supporting companies with thousands of employees. I helped grow its base and product breadth, and it was something that just worked. I was ready for my next challenge.
I’ve learned an immense amount. It’s been fun talking to the customers we first connected with two years ago and seeing how we solved their pain points. When you do such a large build, it’s easy to disappear in a silo. You get feedback along the way, but no one’s actually using the product yet. Now that the product has launched, it’s been so validating to see how everything has played out.
For example, one of the hypotheses we had in place right out of the gate was HRIS plus talent. No other player had gone about things this way — most human resource information systems have started with HRIS first, and then tacked on a bunch of other products around it. Because we started with the talent product first, when we started developing our HRIS, we knew exactly how the information needed to flow across and we knew the customer pain points. That gave us a really unique perspective of the analytics, insights, and different capabilities. We knew that once you have that source of truth in an HRIS, that unlocks capabilities across the entire platform.
We are constantly adjusting. This is one of those instances where it’s really beneficial to be able to operate as a startup inside of a startup. You can iterate and change your mind. You have very few customers, so if you pivot and walk away from one product decision in favor of another one, you’re able to do that with very little ramification. It’s actually net positive, where most companies and customers are happy with that given decision.
We haven’t done any massive pivots, but we have done a lot of augmentation of the existing features we already had in place. One augmentation involves AI features. This is something that wasn’t on the roadmap two years ago but is very much front-and-center for our HRIS today. We continue to gather feedback to understand what AI features will be most useful to companies. Once we have that data, we can enrich our experiences by adding onto what we have in place.
We actually did create a silo — partially on purpose — to lessen the distractions since we were starting inside of a startup. When you’re a 500-person company, roadmapping is a really big process that involves a lot of different people. In our group, we didn’t do formal roadmaps for the first several quarters because it wasn’t necessary — we knew exactly what we needed to do.
We focused on making sure the right processes were applied based on our stage as a mini company inside of Lattice. Now that our product has launched and we have real customers, we’re working much closer with everyone else throughout the organization and following standard processes. It was more of an evolution over time — we went from nothing, to having customers, to now working more similarly to the 500-person company that Lattice is.
After each of our product launches, we add event tracking. This helps us understand how people are using the software and allows us to collect data on who interacts with what. For example, we look at how people log PTO, which can be through the mobile app, Slack, or the product itself. Our goal is to meet people where they work and consider their natural workflows.
We want to build a data-centric mindset from the get-go. That way, when we expand our go-to-market motions and take on additional customers, we’re able to have real insights into what’s working and what’s not working and try to measure the output and impact of the features we’re launching.
I think failure is not necessarily a bad thing, as long as you’re able to call it out quickly. The worst thing about failure is when you continue down a path that’s not working.
When we kicked off our HRIS initiative, we knew employee onboarding was a really critical piece of the puzzle. Onboarding touches a bunch of different parts of the HRIS — it’s all the fields about the employee, the documents the company needs, who’s on the employee’s team, etc. A lot of that HRIS data needs to exist in those initial pieces. We tried to build the onboarding product before we got to everything else.
In doing so, we realized we were going down the wrong path. We had to add too many different hacks to make it work. We ultimately decided to scrap that product entirely, ship the resources around elsewhere, and then revisit it when we had more of the foundational elements in place. This realization enabled us to better allocate the team to higher-value items. They came back to work on this later, when we were more easily able to add onboarding. We’ve built a really delightful experience from those learnings.
We are not a huge A/B testing company. Instead, we’re big on doing small rollouts to a cohort of customers and seeing how it’s working for them before launching more broadly. If we’re doing a big release, such as updating permissions or something that touches different customers, we’ll find a cohort of smaller-sized companies. We’ll measure, see what their feedback is, look at the data, and as we feel more confident about that release, increase the complexity and the size of the companies that we’re running through.
We also love to involve our customer success team in this process to make sure we’re all on the same page. This approach also helps them be aware of certain things. Doing rollouts this way is truly a team effort, but the product teams keep a close eye on the feedback and metrics to avoid any unintended consequences.
Our method reflects the startup inside of a startup. We’ve done it all the way, not just within existing product development (EPD) but also with the sales and success motions of it. For the longest time, it was just our EPD team building the product, but as we started getting real customers, we added a handful of customer success and implementation managers. We now have a dedicated sales rep as well, so our team goes all the way through the full process.
We’ve found that this makes for a closed feedback loop. This is where it’s been fun and exciting to be on the product side — we’re getting constant feedback. After every sales demo, for example, we hear the good, the bad, the ugly, and the common themes.
We continue to look for candidates who can demonstrate deep collaboration. We have a strong triad model of PM, EM, and designers all working together. We’ve seen the most success with that model. Overall, we also look for someone with a growth mindset, deep curiosity, and strong resiliency. In the product role, you’re constantly dealing with changes. It’s important for a PM to be able to roll with the punches and also keep the team aligned and moving in the same direction.
Try to constantly expose yourself to different things and say yes wherever possible, especially earlier in your career. Volunteer to do additional things, learn from senior people around you, and be a sponge. Eventually, you’ll start to develop a pattern recognition of what goes well and what doesn’t.
The hard part about product is that there are a lot of gray areas. Not everything is set and has a black-and-white solution. By having that pattern recognition, you can start to understand how to react and get better outcomes. The more of that experience you get, the easier it will be to move up in your career and within product.
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?
Ezinne Udezue, author and Partner at ProductMind, discusses how she developed a passion for customer listening.
Colin Brooks shares how digital product management influences a traditionally in-person institution — The Whitney Museum of American Art.
We’ve all read “The Lean Startup.” We get the theory. But when it’s time to ship, somehow we mess it up anyway.
Dev Ward shares how she’s helped curate the digital experience for the WNBA’s growing fanbase, including redesigning and launching a new app.
Learn more →
