Brought to you by CustomerIQ, the AI platform to turn customer feedback into value. CustomerIQ discovers and quantifies themes across customer feedback channels like customer calls, surveys, tickets, team messages, and more. Align every team, prioritize work with conviction, and accelerate development with one tool. Learn more here.
JCPenney is an iconic American retail company and key anchor store in shopping malls across the United States. JCPenney traces its origins back to April 14, 1902, when founder James Cash Penney and his partners opened the Golden Rule dry goods store in Kemmerer, Wyoming. Over the next two years, they expanded to other Wyoming frontier towns. In 1907, Penney bought out his original partners and began a journey that would shape the retail landscape for decades to come.
Over the years, the company expanded its operations, was one of the first to introduced credit cards and catalogs, and underwent international expansion and diversification. But from 2012 to 2020 the company faced challenges, including a troubled pricing strategy and the impact of the COVID-19 pandemic, which led to a bankruptcy filing in May 2020.
The company has since been working on a turnaround plan, including a $1B initiative to revitalize its business, focusing on digital capabilities, in-store upgrades, merchandising, and supply chain improvements.
A huge part of that strategy is led by our guest today, Vanathy Lakshmi, VP of Product Management and Experiences. Vanathy has over a decade of experience leading ecommerce product teams at iconic brands like Pier 1, Walmart, Sally Beauty, Albertsons, and now JCPenney.
In our conversation we learned:
- The unique challenge of shaping digital products in retail
- The four-in-the-box strategy
- The importance of a great VP of Product
- Vanathy’s decision-making template
- Using stage-gates in product discovery
- Using a tiered approach to feature rollouts
- What Vanathy looks for in product hires
- The importance of technical skills vs UX skills in product management
Please enjoy our conversation with Vanathy Lakshmi.
JCPenney is an iconic retail brand that’s making a big transition to ecommerce. What unique challenges does that transition present?
Most people don’t realize that retail hasn’t really seen a whole lot of innovation in the last few decades. This makes the problems very complex.
Moving to ecommerce means that the focus shifts more to driving traffic rather than strictly making sales, as many people tend to visit a website to research a product they’re interested in before they actually make a purchase. So essentially, the digital channels serve more as traffic drivers than sales drivers.
One thing that I believe we need a better grasp on is that ecommerce is not a one-size-fits-all operation. Everyone has their own shopping preferences. For example, I might prefer to read an email, click on a link, then shop. And after being followed around by a Facebook ad, I might finally decide to buy something. However, my kids would rather see an ad on YouTube, click on a link, and just buy it.
It’s crucial that we keep these preferences in mind as we plan our ecommerce strategy. At the end of the day, we’re not needlessly trying to attribute customer behavior to the nth degree. What we’re trying to do is understand where we should optimize. What areas should get more attention? Less attention? Which channels should we be focusing on?
And another thing worth mentioning is that many of our tasks are end-to-end solutions. What I mean is, when we make a change to a product, it affects how it’s sold on the website which in turn influences how it’s sold in stores. So you’re always seeing this continual, end-to-end roadmap developing.
How big is the product team?
My team is made up of close to 45 people and I like to split it down the middle between product and UX. Now, UX isn’t just design for us – we’re also talking about conducting AB tests, diving into research, contemplating the full life cycle of our work in UX. And the team we have, well, they are just phenomenal. Always ready to handle all aspects of these responsibilities.
How do you structure the product team?
In structuring our product teams, we utilize what we call the “four-in-the-box” strategy. For every product we build, regardless of the organizational structure or the product manager, we consider this arrangement. Essentially, we have one product leader paired with one UX or user experience person, one engineering squad, and then there’s an analytics alignment. Now, these roles may often fluctuate depending on the scope of the project area – it may not always be one-to-one.
The way the ‘four-in-the-box’ is determined is based on how they all come together, taking into account their capacity and how they are aligned to an outcome. For instance, when we target an outcome like automating segmentation, we form a product crew or product team consisting of the ‘four-in-the-box’ setup.
Now, you’ll see a varying degree of maturity within each of these areas as the strategy evolves. But basically, if I’m told to place a product team on a specific outcome, we strategize on what the four-in-the-box setup might look like. This is done keeping in mind the scope of the outcome. If it’s complex, we might require a leader and two sub-leaders as there might be sub-outcomes within the larger outcome. Further strategizing on what the rest of the team looks like helps shape the team structure and dynamics.
How far out do you plan?
That’s a good question. I’ve never been a big fan of building a large backlog. I believe that, in our industry, if we are truly practicing agility, having anything beyond six months planned out with an nth degree of detail is just a waste of time. That being said, I do consider a healthy two-quarter roadmap to be beneficial. On top of that, I sincerely think it’s critical for teams to have a clear plot or plan of where we aim to be in a year or two. This allows us to think ahead and envision the future. However, we tend to plan more narrowly within a quarter, which I always see as an opportunity for continuous improvement.
What percentage of ideas come from top down vs bottom up?
From my perspective as a middle leader, I regularly see the struggle to balance these ideas. Often, when leaders above me suggest something, it’s taken as a ‘go-do’, or a directive.
But I really think the go/no-go sits in that middle layer more than anything else. Many times, when an executive says something, we take it at face value and execute it. But, is that where our roadmap stops? No, this is where we need to dig deeper to understand the purpose behind what they are trying to say, their expectations, and execute their suggested business strategy. Then product leaders must work with the second level business leaders to build purpose-driven outcomes.
Given this perspective, it’s very hard to put an exact percentage on how many ideas come from top down or bottom up. The crucial part is that there’s a balance and that we understand the ultimate goals behind every directive and use them to inform our roadmap.
Are we perfect at this yet? No, not quite. I think middle leaders, including myself, need more education to master these tasks effectively. That’s the area where we need to come together.
Do you use OKRs?
Yes, we do use a form of OKRs, but we refer to them as outcomes or outcome-driven KPIs. The application of these differs across our organization, with some areas being more mature than others. A challenge I often see is that these tend to be very single-dimensional, focusing on aspects like sales or conversion. This sometimes hampers the team’s ability to progress freely.
What I believe we need to gravitate towards as an industry, is a system where we consider that while these KPIs all ultimately contribute to our broader objectives, they are lagging indicators. The real question we need to be asking is, what are the leading indicators we should be tracking against?
Having said that, this becomes much complex in larger, transformational companies due to the existence of different and sometimes even conflicting entities. For instance, if I introduce a new lever, the impact of my actions can ripple through other divisions. However, it’s this complexity in navigating a bigger organization that makes the job of a product leader interesting.
What would you say is unique or central to your approach, organizationally or professionally?
Changing how we perceive ownership of the roadmap. I used to think I owned it and would push to achieve specific results. But over the last two years, I’ve learned that it’s my team who needs to own the roadmap.
My role, in fact, has evolved into helping my team access different tool sets to assist in their problem-solving efforts and constructing roadmaps. This shift in approach was born out of considerable research and it introduces a unique dynamic that’s absent in many of today’s existing frameworks. The truth is, a common framework may or may not be effective, because every organization is unique. The success lies in adapting a framework into practice and bringing it to life.
For example, within my team, I introduced a template to facilitate decision-making and empower the team members. They were grappling with a sense of disempowerment, feeling as if they should make decisions because they didn’t feel a sense of ownership over the product. But I advised them that their role isn’t necessarily to make the final decision.
Their role is to identify and present the best solutions to their business partners, complete with data, and have partners agree to the best one. They are facilitators, verifying if a solution is effective and gathering sufficient evidence to back up their recommendations. This shift in perception helps to avoid a misunderstanding of their roles and empowers them to solve problems rather than getting caught up in decision-making.
To sum it up, it doesn’t matter so much who’s the decision maker because at the end of the day, what’s crucial is: did you solve the problem?
Tell us more about the template to articulate different solutions
Absolutely! It’s pretty simple, it’s a straightforward guide with two or three options. Each option has its own pros and cons and outlines how various role responsibilities might alter as a result of the work. And then our team puts forward our recommendation.
We use the system across board—up and down the levels—to gain consensus. But mind you, we don’t employ this for every little decision. We use it when we are talking about game-changing decisions that could dynamically alter the landscape.
Through this method, we’ve achieved some brilliant results, which has been awesome to witness. The flexibility of the system has allowed the teams to expand on the template and tailor it to their needs—for instance, outlining what we plan to do for the next quarter or different delivery packages. Seeing how the product managers have adapted this tool to meet their needs has been incredibly exciting.
What is the role of product operations on your team?
As a product leader, I find it near-impossible to expect a product manager or anyone on my team to excel both as a detailed, process-oriented individual and as an innovative expert with a deep understanding of the business. You see, to me, there’s a clear divide there. I’ve seen folks who are strong in process, able to put everything into structure, but not necessarily innovate. Neither skill set is superior; it’s like comparing left brain with right brain. So, I determined that I needed an ops role, specifically a product ops team.
The role of product operations sits like a fulcrum in the team, acting as the lens through which we see the product managers operate and the process of product creation. Interestingly, product ops people don’t own decisions, but they do own recommendations. They provide the tools that the leaders can use to create productive conversations and progress within their teams.
Now, the product ops individuals may not dictate processes, but they suggest and propose. It’s up to the product leaders to take on those recommendations and tailor it to suit their needs, providing feedback to the product ops team to further refine existing standardizations.
The operating model of product ops is critical, extending beyond just the product team. It crosses boundaries to collaborate with business, engineering teams and more, ensuring the operating model’s efficacy. It’s been a fascinating journey, it really has. And the slightly misunderstood role of product ops is gradually gaining the recognition it deserves.
How does product discovery work and how has that evolved?
Product discovery works through a process we’ve implemented called “Stage Gating.” It essentially provides our product managers with a mechanism to run through various stages or milestones while working on a product. This journey typically begins with an idea, which could come from anywhere. The critical question then becomes, when does that idea escalate to a priority? Have we understood its value? Have we linked it to a business problem to solve? Because, let’s face it, every idea can seem cool, but not every idea aligns with business needs.
The discovery phase of product development involves using our stage gates to align ideas with business value. This even allows our product managers to question and analyze random ideas from business partners, to figure out what it provides for the customer and what it would drive.
Once a priority is established, we move on to the next stage where we discover solutions, evaluate options, build, plan, deploy, and finally measure the results. We come full circle to ask: Did we achieve the value we aimed for? If not, why not, and did we actually solve the problem we had set out to?
This Stage Gating process is still maturing. It’s not perfect everywhere, but in certain contexts, it’s been highly effective. I like to compare this to an InstantPot – anyone can own one, but the quality of the recipe you produce is extremely dependent on the cook. Similarly, product ops provides the tools, in this case the “instapot”, and then it’s up to the manager to “cook” the best product solution with it.
How do you capture customer feedback?
We have two dedicated teams paying intense attention to this responsibility. Firstly, we have a business strategy team, which operates closely with the product team. Although the product team isn’t fully responsible for value tracking and such, they do collaborate with this business strategy team on it.
Secondly, we have a research team, with a sub-section who go out, interact with our customers, and conduct all kinds of research. They are in close collaboration with our customer service team, striving to fully understand customer complaints and any other feedback they may have.
Our primary aim with collecting this feedback is to cohesively bring together the quantitative and qualitative factors when we are faced with a decision-making process. If our research team identifies a problem, they bring it to our attention and suggest a fix based on the customer complaints. Instead of rushing to a solution, we take the time to evaluate the value, and understand the quant and qual components of it before we decide how to address it.
At times, we also have a large research group involved in more complex customer feedback. For instance, my team recently engaged in a ‘size to fit’ initiative, which is often overlooked in our line of work. Both quantitative and qualitative aspects came into play as they worked with customers to understand their perceptions and feelings on the matter. Once again, this is a situation where we bring both types of data together to provide the best response and solution for our customers.
How do you go from feedback to roadmap?
When we receive feedback, initially it’s just an idea. Remember the stage gate process we discussed. Every idea has two opportunities to be considered. One in the internal road mapping session, which happens weekly, and the other one at the partner roadmap ceremony.
In the internal road mapping session, we actively discuss the ideas that have come in. It’s a bit of a rumble, really – myself and my leaders assess the potential value of the idea. The objective here is to see whether it holds enough weight to move forward.
If it does, we bring it to the partner roadmap. Here, we collectively agree if this is substantial enough to determine its value and start planning on how to pursue it in the upcoming sprints or quarter. We try not to disrupt a quarter as much as possible, unless of course, the idea is absolutely amazing and needs immediate execution.
So in terms of defining the roadmap, it’s all about evaluation and timing. If an idea is of substantial value and aligns with our priorities, we incorporate it into our roadmap. A critical part of this process is the internal and the partner roadmap meetings or ceremonies as I prefer to call them. They’re crucial to moving through the stage gates effectively.
How are these ideas and feedback organized?
We use Confluence and we often remove stale ideas and focus on the ones that have significant influence. The key thing about ideas is that while there are no bad ideas, not every idea needs to be worked on. We evaluate ideas based on key performance indicators (KPIs). We ask, what is the business value? Is it worth the investment? If an idea passes this test, only then does it get to the discussion stage. For instance, say we have an idea to change a button color from green to blue. We first identify what KPI it affects and whether it ties with our high-level strategic goals for the year. If it does, we’ll pursue it through established validation stages. This approach allows us to prioritize effectively.
How do you manage feature/project rollouts with other departments?
This is an area where we’re always maturing and improving. We have standardized templates for launch communication to work with our business partners that are expected to be part of the rollout. We want to make sure everything checks out before we proceed.
Our approach is typically tiered. We start with a small group, and then we gradually expand it. This way, we can spot potential issues and fix them before rolling out to a broader audience. Admittedly, this can result in us being in reactive mode at times. There can be instances where we’re surprised by unexpected results and we’re left to troubleshoot and fix the issue after it has been launched.
I’m comfortable with this approach though because if we become too proactive, it can lead to a process-heavy system which slows down the movement. I find it more efficient to launch, observe the impact, and then refine as needed, as compared to holding back the feature or project to anticipate and avoid every potential hiccup.
However, I do exercise caution when it comes to changes that directly impact the jobs of our internal team. We deal with a lot of internal and external products, and we certainly don’t want to cause unnecessary disruption or confusion. In these cases, careful change management becomes super critical. Here, I’d rather slow down and think through every role and possible pitfall before rolling out the change.
What do you look for in product hires and what does your interview process look like?
I look for learners. I find that the world of corporations often holds the misconception that a person should already be doing the job before they get the title. I believe in giving people a chance to prove themselves and work towards something. It’s not about whether they’re already doing it, but rather, can they do what the position needs?
My first step in the interview process is to determine if the candidate is customer-oriented.
I accomplish this by asking them to talk about what they did in their previous job. I don’t say, “tell me what problem you solved.”
If they start their answer with technology or something unrelated to the customer, it’s a no from me. If they begin discussing a customer and a problem, then they’ve piqued my interest.
Within the first few minutes of the interview, I can assess whether or not the candidate is right for us. I believe a core understanding of our customers and the ability to root oneself in their problems is critical to product roles. Thus, this understanding becomes a deciding factor in my hiring process.
You have a technical background. How important do you think it is for product managers to have a technical background?
I don’t believe it’s important at all for product managers to have a technical background. Now, there might be situations where it could be beneficial, but that’s not always the case.
For example, suppose we have a data product. Most of the time, you need to engage in thoughtful consideration around the governance and longevity of the data. But this does not require a technical background, instead what it demands is critical thinking.
People often mistake the need for logical reasoning with the necessity for technical acumen. But the truth is, what a product really requires is a stronger sense of logic rather than technical understanding. Logical thinkers, regardless of their background, can excel as product leaders. I’ve had mentors who were English teachers and yet they were great product leaders simply because they had the logical thinking ability.
Therefore, I believe the question we should be asking is, are they logical enough to be able to think through the problem? Can they stair step the problem tree and figure out a solution? These qualities are far more critical than having a technical background. Even if someone had to write a requirement for an API, there would be more logic involved than technicality.
As a product manager, you won’t be asked to write or change code, your job will be to define how things are supposed to work. So, while I don’t see the need for product managers to be overly technical, they absolutely need to be hyper logical.
You’re also a UX enthusiast. How important is it for a product manager to have a UX background?
Oh, I love the rare unicorn who has both UX experience and product expertise. It’s such a unique blend because the UX role is quite similar to an artist’s role. Now, I’m not suggesting that everyone is either artistically inclined or not, it’s just that people’s skills tend to lean towards one or the other.
What I’ve observed is that there are remarkable product leaders and managers who are also stellar UX folks. They typically hail from an analytical background, possessing the ability to objectively examine a problem or solution. They ask, “What percentage of the customers used it?” “How did we resolve this for them?” This demonstrates a knack for product thinking, which extends beyond the role of a product manager. Even my CEO and the Chief Customer Officer, to whom I report, possess this product thinking knack.
Yet, being labeled as a product person requires more than just a title; it’s about the mindset. From this standpoint, I’ve noticed that an exceptional UX person excels at addressing a specific, industry-wide problem. However, there’s room for growth in our UX practices. They should evolve to address more journey-based problems. This journey-thinking approach, albeit rare among UX professionals, can catapult them into more product-oriented thinking.
What are fun or unique traditions or rituals on your product team?
We have a committee that orchestrates all sorts of enjoyable activities to keep meetings interactive, notwithstanding our all-remote setup. We usually kick off meetings with the first 15 to 20 minutes focused on understanding how each one feels.
We also give ourselves breaks on “no meeting” days and schedule cafe breaks. We encourage open conversation within our team through things like our buddy system. This system is inspired by my daughter’s middle school exercise, where she pairs up with a kindergartner. We’ve mirrored it in our team by having each member pair up and become friends with someone they’ve never really talked to before. There’s a fun incentive too – a coffee treat for the duo!
We can also find joy in our work sessions. For instance, our design thinking sessions can be quite lively. You see the team coming out of these sessions brimming with energy and excitement.
Huge thank you to Vanathy Lakshmi for her time and expertise! You can follow along with Vanathy on linkedin.
