Inspired by yesterday's conversation w @HeatherisHungry , @puja108 , and @SomethingWithC on contributing to conversations in the #kubernetes community, here's a mega thread of some lessons learned as a Product Owner at @giantswarm
(1-1/8)-The other day, I was trying to clarify who in the managed apps team should help our customer solve an issue with a managed app. It turns out, the issue is not w the app, but w the customer's NLB setup.
(1-2/8)-If I were doing support for the app upstream, I’d say, this is not our product's problem (and this would be the most sensible thing to do for them). And that would be that.
(1-3/8)-But because we have a more holistic view of our customers’ stack, we could identify where the issue is and refer them to the right people to actually solve the issue.
Regardless if it the issue is caused by the app or the NLB setup.
Regardless if it the issue is caused by the app or the NLB setup.
(1-4/8)-Lesson: Because we manage our customers’ kubernetes clusters and have a more holistic view of their stuff, the value to our customers of our managed apps is amplified.
(1-5/8)-In Understanding Michael Porter (h/t @shreyas for the rec), Joan Magretta’s distillation of Michael Porters’ writing on strategy...
This is Test #4: Fit across the value chain. Is the value of your activities enhanced by the other activities your perform?
This is Test #4: Fit across the value chain. Is the value of your activities enhanced by the other activities your perform?
(1-6/8)-Porter: “Fit has to do with how the activities in the value chain relate to one another.
Its role in strategy highlights yet another popular misconception...
That competitive success can be explained by one core competence, the one thing you do really well.
Its role in strategy highlights yet another popular misconception...
That competitive success can be explained by one core competence, the one thing you do really well.
(1-7/8)-“The fallacy here is that good strategies don’t rely on just one thing, on making one choice ...
Good strategies depend on the connection among many things, on making interdependent choices.”
Good strategies depend on the connection among many things, on making interdependent choices.”
(1-8/8)-In our case, two of these interdependent activities are managing both their kubernetes clusters, as well as the apps on top.
(2-1/7)-PO-ing in this technical environment is valuable.
Crazy as it sounds, it took me almost 18 months to learn this.
(In fact, a few months ago, I almost left, concluding that I cannot contribute meaningfully here. 😅)
Crazy as it sounds, it took me almost 18 months to learn this.
(In fact, a few months ago, I almost left, concluding that I cannot contribute meaningfully here. 😅)
(2-2/7)-Why is it valuable?
Compared to say, a web app, building an infrastructure product takes more time in general.
So the division of labor between product and engineering is extra important.
Product answers WHY (and WHAT). Engineering answers HOW.
Compared to say, a web app, building an infrastructure product takes more time in general.
So the division of labor between product and engineering is extra important.
Product answers WHY (and WHAT). Engineering answers HOW.
(2-3/7)-Without product, engineers often go straight to HOW (of course, it’s their job, and our engineers are pretty darned great at it).
It’s extremely easy to jump to implementation without first asking ourselves if this thing should even be done at all.
It’s extremely easy to jump to implementation without first asking ourselves if this thing should even be done at all.
(2-4/7)-A week ago, an independent security researcher found a vulnerability in one of our components.
Security is important to us. Of course everybody jumps on it!
We start listing workload cluster releases where this version is included (there are 5). We plan patch releases.
Security is important to us. Of course everybody jumps on it!
We start listing workload cluster releases where this version is included (there are 5). We plan patch releases.
(2-5/7)-Then I do my job (ask stupid questions):
“How severe is the security issue? Maybe let's coordinate w customer first (how soon they will upgrade, etc.) before we implement? I don’t want to rush and find out they think it’s not a big deal and do nothing with it."
“How severe is the security issue? Maybe let's coordinate w customer first (how soon they will upgrade, etc.) before we implement? I don’t want to rush and find out they think it’s not a big deal and do nothing with it."
(2-6/7)-The answer? It’s about metrics endpoint and is low risk.
This is already fixed in a new version. Since it’s low risk, there’s no point rushing to and exerting the huge effort to do patch releases. Customer will likely not find it worth upgrading anyway.
This is already fixed in a new version. Since it’s low risk, there’s no point rushing to and exerting the huge effort to do patch releases. Customer will likely not find it worth upgrading anyway.
(2-7/7)-Problem solved. We didn’t need to stop everything we’re doing and switch to this new thing that wasn’t important anyway.
(Yes, that was a proud moment for me.)
(Yes, that was a proud moment for me.)
(3-1/2)-As a non-engineer, PO-ing in this environment is extra difficult.
To illustrate: user research, in general, is difficult.
It’s extra difficult in an enterprise environment where customers are few, and customer relationships and time need to be handled with extra care.
To illustrate: user research, in general, is difficult.
It’s extra difficult in an enterprise environment where customers are few, and customer relationships and time need to be handled with extra care.
(3-2/2)-And to make it extra extra difficult? As a non-engineer PO, it’s extra extra hard b/c I’m supposed to live in my users’ reality.
But their reality is so alien to me! I believe I can get there, but the time and experience needed to do so is immense.
But their reality is so alien to me! I believe I can get there, but the time and experience needed to do so is immense.
(4-1/6)-For a product manager, communication IS the job.
And as @mattlemay writes, “The guiding principle for communication is ‘clarity over comfort.’
And as @mattlemay writes, “The guiding principle for communication is ‘clarity over comfort.’
(4-2/6)-Again, this is extra difficult for a PO in a very technical environment.
Why? Most of the time, I don't understand what the hell is going on.
As such, I spend a tremendous amount of time just trying to understand stuff.
I mean, look at my todo list.
Why? Most of the time, I don't understand what the hell is going on.
As such, I spend a tremendous amount of time just trying to understand stuff.
I mean, look at my todo list.
(4-3/6)-Matt writes, “Asking the obvious can be, and often is, tremendously uncomfortable from a personal perspective.
(4-4/6)-"But from a team perspective, asking the obvious has precious little potential downside.
The worst outcome for the team is that it turns out everybody was already aligned in the first place — which is not a very bad outcome at all.
The worst outcome for the team is that it turns out everybody was already aligned in the first place — which is not a very bad outcome at all.
(4-5/6)-"The best outcome for the team is that you reveal some underlying misalignment that would have proven disastrous down the road — in which case, your willingness to take on personal discomfort might have saved your team from a very bad situation indeed.”
(4-6/6)-Because of 3, asking the obvious (and risking sounding stupid or ignorant) is extra likely and extra uncomfortable. But because of 2, it’s also extra valuable.
Whew! That took way longer than I expected. @HeatherisHungry you told me this tweeting would be easy 😅
Back to the top of this thread
https://twitter.com/chiaracokieng/status/1367148580579012617
This is the real top of the thread 🤦♀️
https://twitter.com/chiaracokieng/status/1367536590650826752
• • •
Missing some Tweet in this thread? You can try to
force a refresh
