You and your company’s product bias
Product people often arrive in their roles from disciplines such as business development, technology, marketing or design. Irrespective of your path into product you’ll obviously end up with strengths in some areas and weaknesses in others. It stands to reason then that you’ve got to protect your blind side. UX-focused product people need to listen to technologists with a keen ear, technologists need to listen carefully to business-centric requirements and turn them into values and constraints — your personal bias informs where you need to focus extra attention.
What I found useful as a model for identifying areas requiring attention in a technology company is to look at the organisation focused through a product bias lens. It’s a really simple idea and it’s easiest just to dive in with some diagrams.
The ideal situation
P is product. You can interpret this to your needs, but to my mind it’s either the singular product manager in a smaller company, or the entire product organisation in a larger company with multiple product managers. The terms used are simplistic representations of the areas of your business. By all means substitute business for sales if you’re entirely sales driven, or UX for marketing if the terminology suits you better,but the point is the distinctive forces shaping your product and an honest appraisal of where you as an individual or your product team sit.
The picture above states the ideal position — product is balanced equally between technology, business and UX disciplines. Product correctly navigates the right path between all three areas and balances the needs of each section properly.
That’s a utopian vision of course, and the key is to strive to excel in all three areas, and understand where you’re weakest.
It gets more interesting when you move the product bias around.
It looks great, but our own engineers hate us and it keeps breaking
In the above, product doesn’t spend enough time with engineering. Engineers don’t get enough time contributing to product planning, and this kind of situation is typified by tonnes of work upfront (usually towards a waterfall style approach) and then ‘throwing over the wall’ picture perfect mockups to the engineers to implement. This completely undermines a tonne of value that engineers add to product discovery — not having engineers involved from the outset is a no-brainer path to poor product creation.
Be particularly mindful of this bias when you encounter smaller companies with non-technical cofounders and engineers brought in to ‘just build it’. Check in with engineers regularly to make sure they aren’t being alienated and make sure you involve them early and always in product planning.
It’s cool bro, we’ll sell it to Google
Depending on your experience with consumer focused app and web startups over the last few years you may or may not see example companies with this bias straight away. The big obvious elephants in the room are companies that don’t have any business model at all beyond growing users. This kind of bias is usually a terminal one. There are and will always be exceptions, but as a general rule, with no product focus on revenue and sales, only true outliers can exist this way. Be very wary of more subtle problems with this slant — a classic is kicking dead dogs — products that don’t have market fit and spending tonnes of time on UX and or technological enhancements when the product just won’t sell.
I found this bias to be common from product managers who come from strong technical backgrounds. It’s easy to fall into a mindset of paying lip service to business requirements and focusing on the beauty of the marriage between technology and design. If it’s beautiful and technically superior but doesn’t ship for three years or misses the core features the first paying customers are interested in (note the focus on paying) then it’s nothing more than a beautiful waste of time.
We move fast, but we’re beatable
I worked in product at a company that suffered from a lack of focus in UX and visual design. In our collective naivety, we all powered on without any real attention to design of our web based products, confident that due to nailing customer requirements (it was a very sales orientated company) we demonstrated the various things worked and kept taking the cheques while side stepping customers questions about how things weren’t actually that usable. It was interesting to watch as the competitive space developed and we lost our first mover advantage, until suddenly we were entirely left in the dust by inferiour products that were plainly simpler and easier to use. We started a massive scramble to catch up, and in a classic double whammy of bad decisions, over-emphasised visual design (made it look nice) at the expense of proper UX (made it a good experience that our customers wanted to use). We righted the ship after a few painful iterations, but it speaks volumes about the strength of the engineering voice (and its impact on me as product manager) in the company in answering sales requests — I repeatedly went to engineers with outlines for sellable features, and we included time for visual polish and some small amounts of UX research, and then always threw these aways to get deliverables out faster. Hiring dedicated UX professionals was how we successfully undermined our bias, caused a bunch of problems, made us stronger and realigned product in the process.
You can keep going with the product balls, and sketch out even more extreme bias:
What kind of organisation has that kind of bias? I leave that as an excercise to the reader.
I’ve found using this simple model really useful when discussing problems within companies I’ve worked with. Try it first at a company-wide level and then do it again sometime for just yourself being honest about your own personal strengths and weaknesses. Stick a pin where you think you’re real biases lie on the circle, and then work hard to address the other sides.