Using a Product Value Curve to Prioritize Work

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I'm sitting down with Lakshmi Uppala. Lakshmi, welcome. Thanks for taking the time to talk to us.

Lakshmi Uppala: Thank you, Shane. It's my pleasure.

Shane Hastie: My normal starting point in these conversations is, who's Lakshmi?

Introductions [01:03]

Lakshmi Uppala: Yes, that's a great start. So, professionally, I am a product and program management professional with over 12 years of experience working with Fortune 500 companies across multiple industries. Currently, I'm working with Amazon as a senior technical program manager, and we build technical solutions for recruiters in Amazon. Now, as you know, Amazon hires at a very, very large scale. We are talking about recruiters processing hundreds and thousands of applications and candidates across job families and roles hiring to Amazon. Our goal is to basically simplify the recruiter operations and improve the recruiter efficiency so that they can spend their time in other quality work.

What sets me apart is my extensive background in very different type of roles across companies and driving impactful results. So, in my experience, I've been a developer for almost seven years. I've been a product head in a startup. I've been leading technical teams in India, in some companies in India, and now in Amazon. Over the last seven years or so, I've had the privilege of driving large-scale technical programs for Amazon, and these include building large-scale AI solutions and very technically complex projects around tax calculation for Amazon.

Outside of work, outside of my professional world, I serve as a board member for Women at Amazon, DMV Chapter, and Carolina Women+ in Technology, Raleigh Chapter. Both of these are very close to me because they work towards the mission of empowering women+ in technology and enabling them to own their professional growth. So that's a little bit about me. I think on my personal front, we are a family of three, my husband, Bharat, and my 11-year-old daughter, Prerani.

Shane Hastie: We came across each other because I heard about a talk you gave on a product value curve. So tell me, when we talk about a product value curve, what do we mean?

Explaining the product value curve [03:09]

Lakshmi Uppala: Yes. I think before we get into what we mean by product value curve, the core of this talk was about defining product strategy. Now, product strategy at its start is basically about identifying what the customer needs in your product. So that's what product strategy is about, and product value curve is one of... very successful and a proven framework to building effective product strategy.

Shane Hastie: So figuring out what your customer really needs, this is what product management does, and then we produce a list of things, and we give them to a group of engineers and say, "Build that", don't we?

Lakshmi Uppala: No, it's different from the traditional approach. Now, traditionally and conventionally, one way to do product strategy or define product strategy and product roadmap is to identify the list of hundred features which the customer wants from your product and create a roadmap saying like, "I will build this in this year. I will build this in the next year and so on", give it to engineering teams, and ask them to maintain a backlog, and build it. But value curve is a little different. It is primarily focused on the value, the product offers to customers. So it is against the traditional thinking of features, and it is more about what value does it give as end result to the user.

For example, let's say we pick a collaboration tool as a product. Right? Now, features in this collaboration tool can be, "Visually, it should look like this. It should allow for sharing of files". Those can be the features. But when you think of values, it is a slight change in mindset. It is about, "Okay. Now, the customer values the communication to be real time". That is a value generated to the customer. Now, the customer wants to engage with anybody who is in the network and who is in their contact list. Now, that is a value.

So, first, within this value curve model, a product manager really identifies the core values which the product should offer to the customers, understands how these values fit in with their organizational strategy, and then draw this value curve model. This is built as a year-over-year value curve, and this can be given to the engineering teams as a... The subsequent thing is to define features and then give it to engineering teams. So it is purely driven by values and not really the features which are to be built on the product. That's the change in the mindset, and it is very much essential because finally, customers are really looking for the value. Right? It's not about this feature versus that feature in the products. So this is essential.

Shane Hastie: As an engineer, what do I do with this because I'm used to being told, "Build this?"

Engaging engineers in identifying value [06:02]

Lakshmi Uppala: Yes. I think when we look at value curves and its significance to engineering teams, there are multiple ways this can benefit the engineering teams. One is in terms of the right way of backlog grooming and prioritization. Now, features also. Yes, there is a specific way of doing backlog grooming which engineering team does, but I think when you translate this into value-based roadmap, the engineers and the engineering teams are better able to groom the backlog, and they're able to take the prioritization decisions in a more effective way because values are, again, going to translate to the success of the product.

Second is the design and the architectural decisions. Now, if we think about the traditional model, right? Because they're given as a list of features, now if an engineer is building for the features, the design or architectural choices are going to be based on the features which are at hand. But thinking in terms of value, it changes their thinking to build for longer-term value which the product should offer to the customers, and that kind of changes the design and architectural decisions.

Third, prototyping and experimentation like engineers can actually leverage the value curves to rapidly prototype and also test design alternatives which, again, is not very suitable with the feature-based roadmap definition. I think one other thing is cross-functional alignment. This is one of the major problems which we encounter or which the engineering teams encounter when there are dependencies with other teams to build a specific feature in a product. It is very hard to get the buy-in from the dependency teams for them to prioritize the work in their plan when it is based on features.

But when you think of value and value curves, it gives a very easy visual representation of where we are trending towards in terms of value generation to customers and how our incremental delivery is going to be useful in the longer run which is very helpful to drive these cross-functional alignments for prioritization, and I know... being an engineering manager in Amazon for a year, I know that this is one of the major problems which the leaders face to get cross-team alignment for prioritization. All of these can be solved by a good visual representation using value curves and defining value-based roadmaps.

Shane Hastie: So approaching the backlog refinement, approaching the prioritization conversation, but what does it look like? So here I am. We're coming up to a planning activity. What am I going to do?

Prioritizing by value [08:54]

Lakshmi Uppala: Okay. So when the product manager defines the value curves, let's say they define it in incremental phases, that's how I would recommend approaching this. So as a product manager, I would define how my product is going to look like three years down the line and in terms of the values, again, not just in terms of the features. I'm going to define like, "Okay. In three years, if I'm going to be there, year one, this is the area or this is the value I'm going to focus on. Year two, this is the value I'm going to focus on". So this is going to give year-on-year product roadmap for the team to focus on.

Now, translating that to the tasks or deliverables which engineers can actually take on is a joint exercise between product managers, and engineering leaders, and senior engineers. Now, translating these values into the features for the product. Again, we are not driving this from features, but we are driving it from values. Given this value, what are the 10 features which I need to build? Creating technical deliverables from those features, that is the refined approach to backlog grooming and planning when compared to older-fashioned backlog grooming.

Shane Hastie: Shifting slant a little bit, your work empowering women in tech, what does that entail? How are you making that real?

Empowering women in tech [10:21]

Lakshmi Uppala: Yes. It's a great question, and as I said, it's very close to me and my heart. So, as I said, I am part of two organizations, one within Amazon itself and one which is Carolina Women in Tech, Raleigh Chapter, but both of these are common in terms of the initiatives we run and the overall mission. So, within the Women at Amazon group, we do quarterly events which are more focused around specific areas where women need more training, or more learning, or more skill development. We welcome all the women+ allies in Amazon to attend those and gain from them.

Similar in Carolina Women in Tech, but the frequency is more regular. Once in a month, we host and organize various events. Just to give you a flavor of these events, they can range from panel discussions by women leaders across industries and across companies, and these could be across various types of topics. One of the things which we recently did in Amazon was a panel discussion with director level women leaders around the topic of building personal brand. These events could also be speed mentoring events. Like last year when we did this in Amazon, we had 150-plus mentees participate with around 12 women and men leaders, and this is like speed mentoring. It's like one mentor to many mentees across various topics. So it's like an ongoing activity. We have multiple such initiatives going on around the year so that we can help women in Amazon and outside.

Shane Hastie: If we were to be giving advice to women in technology today, what would your advice be? Putting you on the spot.

Advice for women in technology [12:06]

Lakshmi Uppala: Okay. I was not prepared for this. There are two things which I constantly hear in these events. One of them is women have this constant fear and imposter syndrome a lot more than men. When women in tech or any other domain, when they're in conversations or meetings with men or other counterparts, women generally tend to take a step back thinking that they're less knowledgeable in the area, and they don't voice out their opinions. I would recommend women to understand or to believe in themselves, to believe in their skills, and be vocal and speak up where they need.

Second is about the skill development. I think one of the other things which I noticed which is even true for me is while getting engaged with multiple commitments, including personal, and family, and professional, give very less importance to skill development, like personal skill development. I think that is very, very essential to grow and to be up-to-date in the market for growing. So I think continuous learning and skill development is something which everybody, not just women, but more importantly, women should focus on and invest their time and energy in. So those are the two things.

Shane Hastie: If somebody wants to create that Women in Tech type space, what's involved?

Establishing a Women in Tech community [13:29]

Lakshmi Uppala: I think it's a combination of things. One is definitely if somebody is thinking of creating such a group within their organization, then definitely, the culture of the organization should support it. I think that's a very essential factor. Otherwise, even though people might create such groups, they will not sustain or they'll not have success in achieving their goals. So organizational culture and alignment from leadership is definitely one key aspect which I would get at the first step.

Second is getting interested people to join and contribute to the group because this is never a one-person activity. It's almost always done by a group of people, and they should be able to willingly volunteer their time because this is not counted in promotions, this is not counted in your career growth, and this is not going to help you advance in your job. So this is purely a volunteer effort, and people should be willing to volunteer and invest their time. So if you're able to find a group of such committed folks, then amazing.

Third, coming up with the initiatives. I think it's very tricky, and it's also, in some bit, organizational-specific. So creating a goal for the year. Like For Women at Amazon, DMV Chapter, we create a goal at the beginning of the year saying that, "This is the kind of participation I should target for this kind of events, and these are the number of events I want to run. These are the number of people I want to impact". So coming up with goals, and then thinking through the initiatives which work well with the organizational strategy is the right way to define and execute them. If they're not aligned with the organizational culture and strategy, then probably you might run them for some iterations. They'll not create impact, and they'll not even be successful. That's my take.

Shane Hastie: Some really interesting content, some good advice in here. If people want to continue the conversation, where do they find you?

Lakshmi Uppala: They can find me on LinkedIn. So a small relevant fact is I'm an avid writer on LinkedIn, and I post primarily on product program and engineering management. So people can definitely reach out to me on LinkedIn, and I'm happy to continue the discussion further.

Shane Hastie: Lakshmi, thank you very much for taking the time to talk to us today.

Lakshmi Uppala: Thank you so much, Shane. It was a pleasure.

Mentioned:

• Lakshmi Sowjanya Uppala on LinkedIn