Shane Eleniak is Chief Product Officer at Calix, a global provider of platform, cloud and managed services for broadband service providers. He has more than three decades of experience creating cloud, software, and networking innovations. Shane has held various product and leadership roles at companies such as CommScope, Alloptic, Corrigent Systems, Alcatel-Lucent, and Telus.
In our conversation, Shane talks about the idea of horizontal value streams in the B2B2C model — i.e., looking at value from the lens of the subscribers, the service provider, and across all the different personas in the platform. He shares how his team thrives using agile timeboxing methodologies, including packaging products on a strict four-times-per-year cadence. Shane also discusses the importance of having an ownership mentality and how teams perform their best when they have a sense of specific accountability.
When we transformed the company, we wanted a B2B2C model — i.e., we wanted to be a service delivery platform for broadband service providers. We focused on service providers being our core customers and recognized that if we are a platform, we need to think through their success as value creation for the end subscriber.
Many companies struggle because they take an inward-out focus on what makes sense for them, their technologies, and their product lines. I believe that the key is working back from the subscriber and thinking about what they are going to value.
If you think of the modern pyramid of needs for these folks, it’s connectivity, security, management, and analytics. We’re all consumers of those types of services, so we can look at it from the perspective of ourselves, our friends, and our neighbors and ask what they value. Part of our approach is then looking from subscribers back to the service provider, and then back to the platform across all the different personas. What are the needs of the service provider as a persona to market, deploy, manage, and support those services? What are all the elements that a marketing persona would need? So on and so forth.
Security is a great example of that as you look at how those needs evolve for the customer. In Calix especially, it’s easy to look at it from a deployment and management perspective. What is operations going to need? What about engineering? Those are usually the obvious personas. We realized that, initially, we were putting a lot of the capabilities into the hands of the end subscriber, but there was no way for the service provider to do it on behalf of that subscriber.
It became clear as we started to work more with the different personas that we have to cover all of those completely before launching a service. How are we going to market it? What will the campaigns look like? How do we figure out who to target? How are we going to support it?
There are always going to be some very tech-savvy consumers and some who are less so. For example, I can sometimes act as IT help for my parents who are in their 80s. This is a day-to-day experience for our service providers. There’s a wide gamut of tech-savviness they deal with. As we became better at recognizing this, we started to understand the needs of less obvious personas.
A lot of this was about learning how to look at it from the lenses that weren’t natural for a product manager. We want to look at what the end experience is going to be and how service providers would deploy this.
Part of it was the recognition that we wanted three elements. First, could we build the initial systems to do the service delivery at the lowest cost? That drove our access and networking portfolio, which formed the first basis to offer these services. Second was this idea of Revenue EDGE — we have a single platform to market, deploy, and manage services, as well as offer support. Everything starts with the systems — that’s the platform behind it.
Third, and the magic of it, was the question, “Whether it’s a smart home, smart business, or smart town, are we delivering all the elements to do this secure managed connectivity?” We continued to drive interesting offerings for the service provider by recognizing they have two needs: driving ARPU and maintaining a high NPS. Those are the two sets of lenses that say, “Do we have the right systems? Do we have a base B2B2C platform with all the right personas?”
We had to fill out and build clouds for marketing, operations, support, etc. Completing that is what’s allowed us to have this level of success. We also aligned our business model early to the idea of B2B2C. Most of the time, businesses try to do a B2B sale and then go off and do something B2C. Our belief is if the service provider is successful, then we’ll be successful. Everything we do is based on their success.
I’m a big fan of lean. You have to go test your hypothesis with your customers. They can see things that the people on your team can’t. We wanted to extend that process and formalize it. One-on-one, you get a certain type of feedback, but when you have a diverse group of people with the same responsibilities, you create an energy and collaboration between them. They start to reinforce ideas and feed off them.
When we set up our advisory boards, we wanted to get a broad set of customers. We got customers from companies of all sizes and organized around persona, responsibilities, and like-minded goals. This opened things up in two ways. One, we were able to evaluate what we’re thinking about going forward, and two, we created an opportunity for discussion about what we aren’t doing and what we aren’t doing well. Where are there gaps? The advisory boards come and raise these issues and ideas.
We’re fortunate because we have great technical sales and customer success organizations that are talking to our customers day in and day out to get feedback. But our goal with the advisory boards was to formalize that. A lot of people will do C-level advisory boards, and we wanted that in combination with user groups. Who are the people that are using our products every day? That persona was the right approach for us to be able to structure this effectively.
I run a very functional structure. I’ve got classic product management, hardware and software development solution test, engineering operations, and cloud operations. I believe in this idea of horizontal value streams where we’re bringing value to personas. We want to think about it across value and all the functions involved from concept through validation, development, and release.
We’ve got program management, technical program management, product management, development, solution test, cloud operations, etc., involved in those discussions — all in that same core team. They’re working together on a horizontal roadmap of value creation.
For example, if we think about things from a marketer’s perspective, that’s a persona. There may be things that we’re doing in our marketing engagement cloud or new managed services that we’re going to create for small businesses. Some of those elements may be specific to the product or tools you’re using, your workflows, etc. Others are, “I need to market this end product to the consumer, and I want to look at it from a marketer’s lens.” That would be a marketing value stream.
I’m also a big believer in what I call a “one-boat philosophy” within products. Some people think there should and will always be a natural tension between different parts of the organization. Focus changes as you go through different phases, but at the end of the day, we’re all in one boat. It doesn’t matter how we got here or where the issues are, we’re just trying to create value for our customers. You need a collaborative approach across all the stakeholders, and that’s my goal with this structure. They all have a sense of ownership of that value stream, the products, and the roadmap.
We use a mix. I’m fortunate that we’re on a 91-day cadence, and I’m a big fan of timeboxed agile. We package our products four times a year, and on the second Tuesday of the second month in each quarter, we release all of our products. We do everything on epics to stories and break down stories into two-week sprints. We’re targeting one of the four packaging events and have those associated milestones.
For us, it’s really about velocity. As we continue to grow, we look at whether we have a good velocity on the number of epics and epics across developers. Not all epics are the same size, so we take a weighted view of velocity. We weigh quality — particularly customer-found defects — and evaluate that as we’re burning down and getting ready for release. After that, how’s the quality of what’s going into the functional solution test? Post-release, what customer-found defects are popping up as we’re tracking adoption?
There’s a lot of planning that goes on before the release clock starts. We do all of our roadmaps on what we consider as C+4 — C means current, and the +4 represents what the next four quarters look like. Then, we’re starting to plan “current and next” in grooming epics and stories into releases. I look for an interlock between product management development and solution test as we kind of groom into that. We’ll start to decide what the next release is going to look like.
As we’re starting to think in advance, we sometimes find long lead epics that could take multiple quarters that we’re grooming in, so we’re tracking those along the way. But, as the basket gets locked in, we’re tracking development and hitting various quality checkpoints. We reach a release readiness checkpoint inside that where we’re looking at the quality of the components coming together, the branch, the quality of the code inside that, what functional test is looking like, and finally, what solution test is looking like on top of that.
Following that, there are mechanics around release management and getting to an actual release — security metrics and scans, FOSS, privacy assessments, etc.
I’ve been doing this since 1990, and for better or for worse, I’ve learned a lot along the way. I try not to measure success based on classic metrics, but from the eyes of our customer and their customer. People are also starting to recognize that, in some ways, it’s about broader ecosystems and platforms, not building point products. Also, we live in a time where data is the new oil. But if people can’t take action based on that data, it’s useless.
Structurally, my most prominent approach has been in the idea of horizontal teams. I’ve always tried to eliminate classic friction and tension points in organizations. I don’t want tension, I want collaboration. Every team has a different view, but I believe in putting on the lens of the personas and understanding that marketing is different from customer support. I need all of those horizontal views.
Overall, I want my product managers to understand why my architects and developers are saying what they’re saying. At the same time, they need to understand why product management is pointing out value in a different area. And once everybody gets to that, we’re all in the same boat. We’re trying to do what’s best for our customers and their customers. We get great innovation and healthy discussions about what the right approach is, whether we’re solving the right problems, etc. From that, we get better products.
I give people well-defined, clear sandboxes to own. I hire people that have an ownership mentality. They want to be builders and own things down my organization — from my leaders down through their leaders. We all do our best when we have a sense of ownership and accountability, even though we’re all doing a collaborative dance.
From a style perspective, I never liked when people told me how to do things. My goal is to coach and develop people to do more and be successful. To do that, they have to feel like they’re supported in doing things their way.
One of the hardest things about being a people manager is wanting to do things your way. But your direct reports have to be the ones to figure out how to do something and be successful. It’s your job to point out what they should think about, potential obstacles, etc., but you want to coach them based on your experiences and let them make their own decisions and develop their own style.
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?
A Pareto chart combines a bar chart with a line chart to visually represent the Pareto Principle (80/20 rule).
Brad Ferringo talks about how he helped develop modern “earconography” — sound language that creates context-driven audio notifications.
Without a clear prioritization strategy, your team will struggle to tackle competing demands and can end up confused and misaligned.
Minimums allow for lower costs, increased agility, and the ability to collect feedback before too much investment has been made.