What It Takes To Be a Successful Product Person: According to Jay Stansell
Concepts anyone can learn in the product management space.
By Tremis Skeete, for Product Coalition
Product Coalition Founder Jay Stansell is arguably one of the world’s forerunners in world of product management education. He’s also a lifelong student of the pursuit of happiness via one’s passions.
Jay has made wise career choices by always choosing to work on products he believes in. He also has obtained a vast amount of knowledge by building his own businesses and applying his product management lessons learned in the process.
When Jay decided to share on LinkedIn what it takes to be a successful product person into “a few words” as he affectionately described, we got together for a conversation to find out more.
In his LinkedIn post, Jay shared a summation of product management with the following list:
1. OKR
2. ‘It depends’
3. Product: a team effort, not solo act
4. Challenges are inevitable; be prepared
5. Engineers can’t fix everything; diverse skills needed
6. Context matters; one size doesn’t fit all
Jay wants the before mentioned to be seen as mastering concepts down to basic ideas, and his intention is to craft points product people can expand upon via research, design, implementation, testing, and learning.
And how can you apply these concepts into your world? Jay explains.
1. OKR (Objectives and Key Results)
Every product person perhaps is aware of OKRs. In what ways would you describe how OKRs have worked for you?
For any product team to be successful, having clear defined goals that clearly articulate change, and a path and a reason for that change — can be summarized really well in an OKR.
OKRs are fantastic when used across teams. Therefore, in my experience, cross functional OKRs with quantitative results generate the best outcome.
2. ‘It depends’
Why do you consider saying the words ‘it depends’ a valuable tactic?
‘It depends’ is really important. If we don’t know enough about the problem, or the solution, or the market, or many other variables — then what we build or design and how we approach a problem or a solution will be variable [i.e. the results can vary i.e. the outcome could differ depending on the circumstances of the situation].
So when a client asks questions in regard to delivering results, couldn’t the answer ‘it depends’ be perceived as avoiding the question?
‘It depends’ isn’t a way out of answering a question. It’s actually a genuine answer product managers can give. If there’s too much risk on the table, the answer ‘it depends’ will [help to] reduce that risk.
3. Product: a team effort, not solo act
Could you elaborate on the importance of teamwork in software design? Why is it critical for product managers to move away from having a solo mindset and collaborate with others?
Because it quite literally requires a cross functional team to not only build a product, but celebrate a product, identify its users, win its customers, and grow success.
It’s important that product managers remain meek, humble, and stoic, and constantly work on their cross functional communication skills in order to get genuine buy in across multiple teams.
4. Challenges are inevitable; be prepared
We’re all aware that it’s practically impossible to have complete knowledge or control over all aspects of product development projects.
No matter how competent we are, we can’t fully comprehend the details of every situation in a given project. Why do you articulate this point, even for the most well-prepared individuals or teams?
I think no matter how confident we are around a problem or a solution, there are always going to be some ‘known unknowns’ or ‘unknown unknowns’.
And when we come face to face with those unknowns, they bring new challenges. And quite often, it’s easy to underestimate the challenge or underestimate the number or type of unknowns.
5. Engineers can’t fix everything; diverse skills needed
Admittedly, I’ve witnessed cases where product managers would just communicate task orders to engineers. Obviously a bad idea. So if having a great engineer does not directly ensure you build a great product, then what you think makes the real difference?
A great product is about that cross functional solution. The Product Manager is there to orchestrate and facilitate incredible solutions that create incredible value for fabulous customers. Therefore, simply placing an order with engineers is not enough to create a quality outcome.
Okay. So we shouldn’t rely on engineers too much because there’s a risk of focusing too narrowly on implementation, and that can lead to losing sight of the value proposition.
But there are moments when teams can benefit from engineers taking the lead on technical tasks. Do you support that?
Yes. There is an exception, which is things like bug fixing. When it’s a known problem and a known solution, go fix it. Don’t need to involve an entire roundtable to identify solutions for that.
But when the problem is unknown, and the solution is unknown, then cross functional team gathering works well.
Sometimes when the problem is known, and the solution is unknown, also a cross functional team coming together can identify much more valuable solutions than just dropping in the most obvious piece of code that comes first to mind.
6. Context matters; one size doesn’t fit all
Based on your point, it’s apparent you prefer to maintain resilience and adaptability in your role.
And when you speak about ‘context’, I’m guessing you’re referring to the dynamic nature of market trends, team dynamics, and customer desires.
Could you elaborate on why a ‘one size fits all’ approach is not effective in product management?
Why one size doesn’t fit all? Because customers are variable, markets are variable. The teams that we work with are variable. How we feel about coming to work every day is variable, and all of those variables represent ‘context’.
It’s important for the product manager to respect all of those and many more variables in order to not get worn down or feel overwhelmed by the amount of unknown and variables on a day to day basis.
