large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

Published on <a href="https://blog.prototypr.io/the-product-team-and-the-elephant-fa5108b55792?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Carlos Oliveira 
The ancient Indian fable goes that once, an elephant was brought to a village of blind men. They had never been in the presence of one, so as the extraordinary animal stood in front of the men, they would touch it and feel it to learn the details and intricacies of its shape.
Each of the men would touch a different part of the elephant, and would go on to describe the elephant as their experience allowed.
Those who touched its tusks, would say the animal felt hard and pointy and made of marble. Those who touched its side, and feeling a tall, rugged surface, said the elephant felt as if it were a wall. Then those who touched its ear came and said the elephant was nothing of the sort. They thought it was thin, flappy and was more like a fan.
The men argued for a while but couldn’t reach consensus. They refused to understand how others could so stubbornly stand by their (undoubtedly flawed) perspectives. They argued and some even came to blows, until one of the elders demanded they stopped and listened to one another…
<img alt="" src="https://cdn-images-1.medium.com/max/739/1*Omqc86YVsT4EX_UXa6n5Og.jpeg">Source: <a href="https://robertwwilliams.wordpress.com/2017/01/09/six-blind-men-the-elephant-a-modern-fable/">Robert W Williams at WordPress</a>
<h3>The elephant in the open space</h3>
Nowadays, Internet companies try to organize their teams into small, self-organizing units, with all the skills they need to solve problems. Amazon is famous for its <a href="https://blog.bufferapp.com/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done">2-pizza-rule</a>, Spotify has <a href="https://medium.com/project-management-learnings/spotify-squad-framework-part-i-8f74bcfcd761">squadified</a>, Google and Facebook adopted similar models, and recorded research on ideal team size goes back at least <a href="https://hbr.org/2012/08/why-less-is-more-in-teams">a hundred years</a> (spoiler alert — it’s 4 to 5). Organisations are building full-stack teams to tackle meaningful problems in bite-sized chunks in a lean way. Lean and Agile, supported by the rapid evolution of specialized SaaS, have tightened the feedback loops and eased the learning curve so everyone can learn faster. The <a href="https://en.wikipedia.org/wiki/Red_Queen_hypothesis">Red Queen effect</a> has made everyone accelerate and shipping stuff is exponentially cheaper.
However, building good teams with high collective intelligence is still extremely hard. <a href="https://youarenotsosmart.com/2017/10/01/yanss-111-some-groups-are-smarter-than-others-and-psychologists-want-to-understand-why/">Recent research</a> suggests that highly successful teams have 1) a balanced share of voice per member, 2) high emotional awareness and 3) lots of women!
So in essence: you need to hire great humans (especially women). This hints at the fact that a culture of high emotional awareness and balanced team dynamics that enable and encourage members to speak up and participate is critical. So, particularly when looking at multidisciplinary teams, you’ll need to carefully design systems of incentives to make that happen.
You’ll need managers, product engineers, testers, SREs, designers, researchers, marketing folk and anyone else within 2 degrees of separation from your product delivery loop to acknowledge they’re all looking at the problem from different frames of reference. Different disciplines need to be able to see the forest from their own trees.
<blockquote>Team members need to acknowledge the elephant in the open space.</blockquote>
<h3><a href="https://jobs.netflix.com/culture-at-netflix">“Loosely Coupled, Highly Aligned”</a></h3>
If your incentive structure is too biased in favour of one function, one business unit or a set of metrics that don’t reflect the reality of your business, disfunction will take over.
The blind men who have been favoured by the god of KPIs will take the lead, disregard reports of other elephant parts and optimize for their framing of the problem. This won’t make sense to anyone else, some of your best people will stop believing the mission and surprise, surprise: they will leave.
<blockquote>Dan Ariely tried to warn us: <a href="https://hbr.org/2010/06/column-you-are-what-you-measure">You are what you measure.</a></blockquote>
So if that’s true, when defining what you are, listen to your people. Good strategy breeds alignment, that’s why it’s so hard. Create strong, uniquely opinionated strategic guard rails that give your people space and time to invent, create and hone their passions, without straddling them to too much specificity — leave the tactics to those close to the pitch. Make sure there’s room for individual disciplines to thrive, while providing clear goals that everyone can contribute to.
<h3>Share of voice in team goals</h3>
Conflicts often arise from low emotional and situational awareness, information asymmetries and/or misaligned incentives. The danger in team building often lies in failing to create strong alignment between individuals’ motivations and corporate goals.
Say your newly promoted “Head of &lt;insert function here&gt;” is given unbounded freedom to work through your team’s OKRs. More often than not &lt;insert function here&gt; will be Engineering or Product. As one of the blind men surrounding the elephant, they’ll feel what’s right in front of them, make a decision with what the information they have access to, and prioritise the set of Key Results that they can feel. They optimize for their function, background, expectations and personal interests. Inevitably, this leads to products that are either a) overcomplicated and have little connection to users’ needs or b) ambitiously designed but with little to no consideration for the long-term effects of the technical shortcuts that had to be taken in order to meet viable timeframes.
The blind men need to stop talking, and start listening. When defining goals from the bottom-up, share of voice is critical. When setting goals top-down, clarity (of targets and their reasoning) is essential to avoid teams falling into emotional traps. Ideally, your organisation should do both and inform each other.
<h3>Personal incentives</h3>
Another layer of complexity in team alignment comes from personal goals. You’ll have passionate individual contributors, people managers, altruistic task-rabbits, competitive go-getters and fast followers. They’ll see themselves running the team, running a department or even managing the company. They’ll see themselves with large-payoffs that allow them to help their families, working for their dream company or just having enough time to ship their side projects alongside their professional careers.
They all want personal progress and you need to enable individuals to develop the characteristics that sit at the intersection of their individuality and the company’s goals.
When specialists sit in multidisciplinary teams, give them the ability to master their craft. Promote functional critiques, design reviews, off-sites and meet-ups (see also <a href="http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify">chapters and guilds</a>) to allow them to cooperate, compete, evolve and cross-pollinate.
Lay the foundations for the level of emotional intelligence required to create great teams by allowing individuals to thrive. Give autonomy, promote mastery and build purpose. Enable creative confidence. <a href="https://www.amazon.com/Let-People-Surfing-Education-Businessman/dp/0143037838">Let your people go surfing</a>.
<h3>Trading places, competitive altruism and building empathy</h3>
Finally, real empathy is hard to come by. When experience offers you a framing that has worked for you in the past, resetting it can be extraordinarily difficult. Teams should engage in trading places regularly — have designers and engineers work directly together, watch each other building things and understand the complexity in the detail of bringing any idea into the world. Have Product Managers share stakeholder management hardships, involve engineers in problem space exploration, the hard trade-offs and the uncertainty in every decision. Have everyone sit down with customer service. Make data analysis and experimentation a part of everyone’s day-to-day.
Building empathy takes time and effort, but it gives everyone the confidence to reframe the problem using others’ perspectives, which is why it pays off handsomely in the long run. It strengthens bonds and builds trust through understanding, allowing mechanisms of <a href="https://en.wikipedia.org/wiki/Competitive_altruism">competitive altruism</a> to emerge. All the blind men can give each other what they need, signalling their cooperative nature to the group and expecting others to take a step back and their framing of the elephant in the future.
<h3>Make the hard trade-offs — Use the lens of customer-centricity</h3>
At the end of the day, hard trade-offs will have to be made. Teams and organisations will need to decide where they draw the line, what will make them go the extra mile and what they think is not worth the effort given their circumstances.
The advice here is simple — be customer-centric. Help your customers make progress. Prioritise not what they ask for, but what they need. And be sure to keep a healthy balance between fast-paced <a href="https://medium.com/@colivetree/delivery-and-delight-are-you-keeping-score-6819e0c7b84">delivery of new, innovative stuff and details that delight people.</a>
<a href="https://blog.codinghorror.com/boyds-law-of-iteration/">Remember Boyd’s Law: Speed of iteration beats quality of iteration</a>, so decrease batch size, keep shipping things that matter, together — the faster everyone understands what the elephant looks like, the better your product will be in the long run.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=fa5108b55792" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/the-product-team-and-the-elephant-fa5108b55792">The product team and the elephant</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

The product team and the elephant

The product team and the elephant

Top Stories