What I have learnt being a designer, developer and product manager.

It’s approx. 19 years now since I first earned payment for my ability to use a computer. In that 19 years I’ve had a vast number of different roles and some of them have been mentally draining whilst most have been constantly built around growth (i.e. learning from failures etc.). In this time I’ve come across a few things that we seemed to be destined to repeat over and over no matter how many places I work and how experienced my fellow computer horde members are.

Before I outline these let me start by saying I have been programming more in my life than at times I get to design and when I can’t get the designs I want from the design team, well, I always end up doing the actual designs anyway. I often find people that I work with can’t compartmentalize the idea or notion that someone can do both equally well as another, in that you’re always defending your position in the developer vs designer discussion. In reality you’re always nearly often asked “pick a side and stick with it” or face career penalties should you try and sit idle in the middle.

That’s however until I discovered the role of Product Management and what better place to learn that role than when I was at Microsoft. I mean I had some wins for sure but I spent a lot of my time watching absolute brilliant minds at work. In this role working others in this field, I learnt being a developer & designer had benefits as I was now able to look at both sides of the equation and get a sense of what my audience (.NET developers & designers) needed the most from us.

What have I learnt overall in 18 years?

Humans and Chunking.

Some would call this Agile but at the end of the day we humans tend to break things down into small pieces as way of coping with scale (kind of like Neurons in our body aren’t complete end to end cycles, they are really just iterative linkages of energy). Sure we build ceremonies around the problem and often swear “this is the winning formula” but in truth all we are doing is taking a really big lumpy problem and breaking it down into manageable pieces. There is strength in doing this but there is also problems that often outweigh the positives.

For instance in software I’ve noticed teams always almost get caught up in the idea that once you break an object into small pieces it becomes more manageable. In reality this often leads to context or peripheral awareness of the problem being lost due to the fragmentation. That’s the issue it’s not the idea of breaking things down its when the breaking things down gets obfuscated or leaves others out it in turn gives the developer or designer a small amount of information to work from. This in turn creates problems as without context of the problem, intended audience or even why the problem should be worked on… well…. More problems emerge. To put it bluntly you always almost end up doing keyhole surgery — some can make it work others, end in a painful career stunting failure.

A Product Manager is like a Military General.

We often in the delivery teams (developer/designer) roll our eyes at times at the role of Product Manager. We at times have this distrust for anyone that can’t develop or write code to therefore be in charge of the products direction. Then on the flipside I’ve seen teams punish a Product Manager for having the development background because that person can’t resist from checking in on their code base and outlining solutions to problems before they arrive (oh btw, Scott Guthrie used to check name spaces on code before the devs could release…so don’t fault people for that!)

A bad or good product manager is like a General in an army, should they give you bad orders or send you down the wrong path you can easily take a winning high performance team and run them into the ground in under a month. It’s very easy to kill the moral of a development team under the vision or guidance of bad product management (including release management).

Release Management is the same as horoscope reading.

I’ve seen way to many teams be held hostage to a deadline they have little or no control over. Sure Agile processes get placed on a pedestal that is until the business throws a tantrum and says “I need it now” in which case agile will not be a safe haven to hide behind if it even hints at being a reason for delays.

Agile however is often used to manage this and it can work to hold back the release date demons but I’ve also seen Agile become this lumpy carpet in which bad product design or strategies hide under. It’s easy to bury a team with no thinking or strategy behind feature development as all you have to say is “We’ll iterate our way out of this” and unless someone in the room is sharp enough to catch them in the act (empowered as well), guess what…that beloved agile just became that noose around your career necks.

Agile also is a funny and interesting thing I’ve noticed in probably 8 years or so travelling around Australia/World. I’ve honestly never seen teams actually do it right to the letter of the law. I always see them cherry pick it to death and I’ve lost count at the number of times I’ve seen teams argue “well we like to keep it simple” as their rationale for its adoption hackery. I’ve also seen teachers of agile rant “You’re doing it wrong!” to which I now wonder if the builder blaming the tool is the right course of action here?

Suffice to say Agile + Release Management is always an amusing sociological experiment to witness. It often is in many ways like watching the TV show “Survivor” + “Amazing Race” inside the cubicle.

Design is on a pedestal until pressure builds.

As a UX person now (also now studying psychology), I’ve come to learn that we humans are actually quite adaptable to change and experiences. We often place ourselves in compartments and use personas as a shield to hide behind the various matrix’s that we assume or intend users to uphold. It’s as if we assume out loud that our users will self-divide into sub-tribes that fit in with our mental models around usage & expectations.

It’s an ongoing science HCI without any hint of complete understanding but in the mean time we’ll continue to evolve design in a way that hopefully proves probabilities and our internal monologues about what users like or don’t like in designs.

Design is the term though as at the end of the day despite all the research it comes down to the hand of a designer either using a mouse or Wacom graphic pen (most designers I know don’t use a mouse). We can craft the ideas or belief system but its not until these folks grind the pixels out that we have a well formed output that the users can appreciate and be drawn into.

Marketing also play a role in this and they’ll often want more influence or say into what the design composition upholds — in fact everybody wants input as because its visual this means everyone gets a say!. Yet nobody volunteers to have input in that line of code you wrote or even that decision you made around a campaign.

A designer is Queen/King that is until he/she accidently and stupidly shows the rest of the business what they made and then you watch a positive or negative feeding frenzy take place. The feeding frenzy often however is used by developers as now they to have a safe haven to also hide behind as all they have to say out loud is “I can’t do design, so I can’t finish this until the designer finishes”.

Hiding behind that means they have to take no risks or never fail in both their execution of an idea or worse keep their efficiency returns high (i.e. why bother trying to do a design ahead of the designer when all it would mean is wasted time, time…in agile….time…you say)

What have I really learnt?

That despite all the knowledge and experience I’ve acquired over the years it’s really rare I see the business, technical and design equation balanced. Almost every company I’ve consulted with, worked in, contracted for and observed have always managed to have an imbalance in these three areas. If the balance tips in say technical favor it usually means business & design are at a loss and likewise if the other two do the same. You may find one or two areas where the balance stays true or looks balanced but it usually is a false positive as seemingly its usually the “design” that’s the one bluffing (ie crap design experiences being palmed off as “good enough”).

My theory or something I’m going to devote I guess the rest of my life to is finding a way or rhythm to debunk this equation in that there has to be a way to balance the three without cubicle combat.

Today I’d simply say this, if all three parties aren’t sharing the risk of change or failures, then that’s the starting point. In 20 years I’ve rarely seen all three take that on willingly and accepting that failure has rewards as well as losses. That giving a deadline to a developer is like yelling at a tornado to turn around, it may feel good to do so but you will always most certainly get creamed anyway.

A designer is the user advocate and they have instincts built in that are well honed towards how people deal with vast amounts of information & cognitive load. An Engineer can work in literal form better than lateral but a designer has only lateral so the balance has to be struck (form vs function wars begin).

Lastly a Product Manager without a 2+ year roadmap isn’t a product manager, they are just the business development suit running around pretending they are in charge of an empire that has enormous of opportunity that continues to go wasted. If you haven’t got a forward thinking General then maybe the competitor does and that’s why you seemingly keep looking at what they did for visual cues on success vs fail (Microsoft we agonized at Apple/Google/Oracles growth. I doubt it was a two-way process hence the huge leads they have gained in 8 years).