The Right Product Team
With so much onus on the term “right” over “the right product” or “the right team”, is there anything like a "right product team" or is it just an overrated / mythical term? Find out in here...
Talk of posts stemming out of various product people across the world, it’s pretty evident how there seems to be so much of an onus on how everything ought to be right, always:
building the right product
building the product right
building the right teams
But is there anything like a “right product team” in reality? Also:
what does the phrase “right product team” mean & what would its composition look like anyway?
and just supposing there was, how would that team function?
What’s a right product team?
People mostly talk of the concept of a “triad” in product teams which more or less looks like this:
The Product team comprising majorly of product managers who start off by discovering and defining the problem spending enough time over analyzing whether that’s the right direction to take whilst defining what success ought to look like & how they’d go about earmarking metrics that help them track and measure it all.
The Engineering team is largely made up of engineers who govern the build phase and help bring the product to life getting down to the nitty-gritty of the functionality bit of it and they may start off with understanding what’s to be built & then go about delving into how they’re going to do that whilst also being accountable for those intervals spanning all the periodic releases.
The Design team as the namesake does indeed govern the whole design of the product, but alongside that they also go about iteratively ideating, researching, defining, designing and dishing out some great user experiences sans which the product may not be complete.
But, I’d like to draw your focus to one graphic.
Here are average conversion rates sorted over business verticals in the year 2023:
As is evident “Professional services” seems to be the frontrunner with 4.6%. That’s like less than 5 out of 100.
As a founder or a product person working in such a team, would you be happy for that kind of a conversion rate?
The answer is most probably a “NO”.
Given that, it’s only obvious that there may be a problem somewhere.
This visual here attempts to express problems faced by product teams.
“And boy! Aren’t we all guilty of finding ourselves & the products / features we built fitting into either of these buckets!?”
When these ubiquitously get quoted as reasons, everyone seems to largely miss out on and nobody ever seems to quote this one as more often than not it actually is a reason for all the ruckus and the downfall:
The TEAM
Which ought to bring us to the next obvious question:
What makes it a right team?
The answer to that could be covered over 3 different dimensions.
01) Leadership & Autonomy
There ought to be a lot of thought going into how products are to be built, no doubt. Just as much as that is important, it could also be equally crucial to get down to and address these questions as a precursor:
How much of freedom or leeway are they allowed in building product?
What’s the intervention of EXECs & leadership across the stages of the PLC?
It could all boil down to the autonomy teams are given. The HIPPOs intervening or preempting the process of product build, micromanaging daily operations, calling the shots individually over the workflow could only prove to be detrimental. Although one may think that could be a good thing at a startup when there is literally no hierarchy and how one person could be found donning multiple hats each representing an eclectic set of responsibilities, its certainly doesn’t augur well for teams and orgs.
02) Innovation & Methodologies
When innovation could mean engineering and technological advancements to a lot of people especially operating in the Tech space, it could be crucial to that it spills over and goes beyond merely that to cover the mannerisms of teams, the methods used to build products over the workflow, after all TTV (Time To Value) is a metric with a sort of a hypergiant-ish significance.
When going LEAN makes a lot of sense given today’s timeline, it is important to think of it as a mindset covering everything else beyond just the product build alone. The Hypothesize-Design-Test-Learn loop as covered by Dan Olsen in his book The Lean Product Playbook makes a lot of sense to inculcate as a habit within teams and adopt as a de-facto here.
Given the emphasis of putting something tangible in front of the users as quick as possible and testing them out thoroughly over parameters that make sense so as to gain feedback iteratively and let the products course correct, the skeletal landing pages do make a lot of sense. Also, going one step ahead would be to adapt to Smoke tests / 404s, Elevated Trapdoors strengthening one’s arsenal of rapid testing which could be a super-LEAN set-up so to speak.
03) Experimentation & Learning
There is a lot of emphasis evident on hypothesis & experimentation given that teams seem to have adapted to the LEAN way of building products. But think about this for a second:
What’s more important?
the no. of ideas generated?
(or )
the relevance of the ideas generated?
One could keep generating ideas and keep experimenting but to no avail and no end literally, when that bucket labeled “learnings” could end up having barely anything filled in it over a period of time. So, the onus ought to be on the relevance and strength of the ideas generated which then ought to be prioritized and earmarked for experimentation.
But how does one go about getting to that stage of generating impeccably strong & relevant ideas?
The answer lies in “product thinking” and “product sense”.
The importance of deep product sense & product / visionary thinking just can’t be ignored here. In fact, it would certainly make more sense if this supersedes the experimentation bit as it would largely govern the relevance & strength helping add solidarity to the teams concerned.
But above all these there’s one thing that chiefly governs the success and also sets those successful & high-performing product teams apart from the otherwise good-ordinary ones & that is:
“The Entrepreneurial Mindset”
“Imagine if every team member across the org., starting out with the product team of course, but inclusive of the market-fronted ones like marketing, sales, support to the ones governing the build - design & development possessed an entrepreneurial mindset & then had an absolute autonomy over their share of outcomes, there could literally be nothing that could stop them from hitting those pinnacles of success, repeatedly, time & again”
As much as I’d like to cover “entrepreneurial mindset” as a topic here, its onus & significance could be so mercurial, so immersive widespread across the teams of an org. that it looks good for an entire post…