Product nightmares in 15 comics

Working in a product development is wonderful. However, from time to time it can be a bumpy ride. Product positions in a company are at the intersection of individual effort and organizational structure. It’s a passionate dance between the structure and your own cognitive biases. Sometimes it’s hard to distinguish where the root of the obstacles lies. We’ve all seen product people complain about structural limitations, when in fact the cause was their own behavior. And vice versa, when talented individuals run into a bureaucratic wall that prevented innovation.

However, we all face challenging and interesting situations on a daily basis. I wanted to poke a little fun at the challenges that product owners, product managers, and their teams encounter, so I drew a few simple comics. Creating doodles is a hobby very dear to my heart, but it’s not my primary job. I’ve been in a product for almost five years now. It’s an amazing role that constantly urges you to brush up on your analytic acumen and people skills. But when you start to juggle user needs, tight deadlines, company goals, and the needs of your team — you’re bound to make some mistakes. After a few moments of self-pity you get up, shake the dust from your shoulders, and embrace those unpleasant steps as they force you to step out of your comfort zone and grow professionally and personally.

So, let’s discover an entertaining angle to all those little challenges. Here are 15 cartoons of what can you expect when developing a digital product.

Clear priorities

Protect the team from interruptions…and yourself.

Now would be a great time to run.

Down the b(l)acklog hole.

Your “to do” column needs some spring cleaning, or you won’t be able to provide your team with a clear vision and a well-defined sprint goal.

Ouch.

Yep, it’s so hard to say “no” to all the cool ideas. But if you put everything in your backlog, it will stink like the dirty dishes left in the sink for weeks. You’ll lose focus.

So, you don’t have a sprint goal.

It’s kind of your job to take care of this, but what if it slips away?

Phew, that was easy.

All those meetings.

Is your calendar full?

We have so much to talk about.

Stakeholder management

Problems, not solutions.

It’s only a 5 minute thing for you, right?

It’s hard for stakeholders to think in terms of problems, so find your inner Socrates and try asking a bunch of “whys”.

Will you break the promise?

Will you keep it?

You should move away from sales-driven development. Definitely check out Melissa Perri, who approaches product-sales relationship from an interesting perspective.

Always ask for numbers

Hiding behind plurals won’t do the trick, yet many will try.

But what if he’s a big influencer?

Oh, double check that number.

Never too careful.

That cute little confirmation bias. It constantly makes us favor the feedback that supports what we already believe in.

Gradually, you discover how to approach requirements like these. You need to listen carefully and understand the feedback, but ultimately your job is to fit those requests into a holistic perspective. Feedback is always useful, but you should strive for quality as well as quantity.

Tip of the iceberg.

It looks so easy on the surface.

Your job is to understand the complexity behind your product and all the dependencies it dances with. But non-tech colleagues will tend to focus only on the visible side of the product. It’s useful to learn how to present complex entities in a way that is easy to digest. Being a cartoonist with a sociology background, I find myself drawing abstract systems all the time. Visual representations of the complexities really help convey the point to the listener.

Great examples of visualization patterns can be found in a book “Toolbox for the Agile Coach — Visualization Examples” by Jimmy Janlén. It is intended for Scrum Masters and Agile Coaches, but it gives you a glimpse into different visualization techniques. It will inspire you to draw and visualize your work. No advanced drawing skills needed.

Test everything.

Just one quick MVP away.

Sometimes the “M” stands for “maximum”

Surely, you’ve seen something like this before. What will our users think when they see clearly unfinished work? However, MVP testing is not the time to turn on the OCD and perfectionist mode. If you want to test something, it needs to be a simpler test.

Fake door test.

It may sound like a controversial tool if your product has a certain reputation, but it can have alternative uses.

So fake it faked itself.

Product discovery.

Because users don’t bite, but research could.

At least we tried.

Some teams complain they don’t have enough resources or autonomy to do research. Before you start, learn what your maneuver space is. There should be ample ground for you to play on. If you don’t understand it, you should openly ask. It’s better to be open about organizational limitations with your superiors.

If you want to dive deeper into the discovery subject, the book “Inspired” by Marty Cagan is a great read. Cagan recommends the method described in the book “Sprint” by Jake Knapp, John Zeratsy and Braden Kowitz, so definitely check it out. Also, follow Teresa Torres, she gives great insights on discovery.

Results tracking and celebration.

We shipped it!

It’s the delay of gratification problem. You and your team have worked so hard for all this time without that dopamine boost. Shipping a feature is like proudly parading a newborn Simba to your animal kingdom. Everybody needs to feel valued for their work, but it’s so easy to forget about the problem you initially started with. And you just continue to the next feature in your little feature factory.

You should be happy about shipping and encourage your team to blow off steam. Give each other a high five and raise a glass to your hard work, because those little ceremonies bond the team. But tomorrow, your focus should go back to the outcome you intended to accomplish.

I’m not a robot.

You may not want to discriminate against the poor robots, because the results were so good. But then again, bots won’t pay for your product.

You can use bot filtering in Google Analytics, or distill your internal tracking with an updated bot library. It’s easier to just to put a “Is bot traffic filtered?” question in your acceptance criteria, rather than give your happy team a cold shower of bot-free truth.

That’s it for now. Thank you for reading. This is my first Medium post, so I would be very grateful for any feedback.

I’m naming this cartoon series “Productmare”, and I plan to draw more of them as product world has a lot of situations to be inspired from. So stay tuned, more cartoons are on their way!