Product Punks

By Toby Rogers

Constantly context-switching, how technical you need to be, and who should write user stories

#4・
573

subscribers

14

issues

Subscribe to our newsletter

By subscribing, you agree with Revue’s Terms of Service and Privacy Policy and understand that Product Punks will receive your email address.

Toby Rogers
Toby Rogers
Hello fellow punks! 
Welcome to the 20 of you who’ve signed up for this since the last issue I published. It’s great to have you on board. Hopefully you’ll stick with me while I figure out what this newsletter is all about.
Here’s this week’s issue ⬇️

Constantly context-switching as a PM is hard
Apache helicopter pilot
Apache helicopter pilot
One minute you’re thinking about your long-term product strategy with frameworks like the GLEe Model, the next you’re trying to figure out what you need to do with a new bug your QA team just told you about.
Sometimes, it feels like you’re being forced to look at your product through opposite lenses at the same time which can be massively disorienting.
Flying an Apache almost always meant both hands and feet doing four different things at once. Even our eyes had to learn how to work independently of each other. A monocle sat permanently over our right iris. A dozen different instrument readings from around the cockpit were projected into it. At the flick of a button, a range of other images could also be superimposed underneath the green glow of the instrument symbology, replicating the TADS’ or PNVS’ camera images and the Longbow Radars’ targets.
The monocle left the pilot’s left eye free to look outside the cockpit, saving him the few seconds that it took to look down at the instruments and then up again…. New pilots suffered terrible headaches as the left and right eye competed for dominance. They started within minutes, long before take-off…. As the eyes adjusted over the following weeks and months the headaches took longer to set in. It was a year before mine disappeared altogether…. I once filmed my face during a sortie with a video camera as an experiment. My eyes whirled independently of each other throughout, like a man possessed.
How technical do you need to be as a PM?
There’s a long-standing argument about the technical skills you need to be successful as a product manager.
On one side, there are those who say you need a computer science degree if you want to reach the top On the other, there are those who say it’s the soft skills that make the difference, not knowing how to code.
Really, both miss the point.
Being technical as a product manager has nothing to do with your skills and everything to do with your understanding.
And your willingness to learn.
At the very least, you need to have a strong enough working knowledge of the technologies underpinning your product to be able to hold your own in a conversation with your engineers.
You need to understand the technical architecture and the logic behind how you’re building stuff, but that should come from drawing things on a whiteboard, not reading lines of code.
I posted a thread this week with some of my favourite resources for improving your technical game 👇
Toby Rogers 🚀🤘
You don't need a CS degree to be successful at product management.

But you do need to be willing to learn.

Here are 9 resources guaranteed to help any product manager improve their technical game 🧵 ⬇️
Who writes the user stories, anyway?
Another thing I’ve been thinking a lot about recently is user stories. And, more specifically, whose job it is to write them.
In a lot of organisations, it’s the product owner or product manager’s job to write user stories and carve them up into Jira tickets for the team.
But that goes against the whole point of user stories in the first place.
User stories should be informal descriptions of features from the perspective of the user.
They’re a way of expressing the value your product is delivering to the customer in a way that prompts discussion and collaboration around the best way to achieving it.
Like Allen Holub says 👇
Allen Holub
User stories are discovered, not invented or "written." Have a conversation with your customer/users about their work—what they do and why they do it. Take notes on a card. That’s your story.

A PO sitting alone at a desk "writing stories" is dysfunction, plain and simple.
If you’re writing them on your own, then there’s something wrong with your process. Even more so if you’re writing them without talking to your customers.
mirza besirovic 🇺🇦
Here’s an idea: make the user write the user stories… by talking to them.

🥁
That’s it! 
See you next week. 
Toby 
The Punk PM 
P.S. Feel free to share this with anyone else you think would find it interesting.
I’m still playing around with ideas for content and format for this newsletter, so I’d love to hear your thoughts. Go ahead and shoot me an email with ways you think I can make it better.
Did you enjoy this issue? Yes No
Toby Rogers
Toby Rogers @tobiasrogers

Product management musings from your favourite Punk PM

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.