Here’s how it should go:
PM: “Hey gender/ethnic neutral Engineer, I have a genius idea for a new product: I’m calling it “Bamboo Dreams”, a social network for drunk pandas…..”
Engineer: “Your “genius” idea sounds great, mind elaborating a bit more…?”
PM: “You’re right, a one line spec probably isn’t fair, how about I write a one-pager, and if I can’t fit it into one page, then it’s probably not worth doing, sound good?”
PM: “Basically, I think drunk pandas are an untapped market for our company. They are hugely valuable to bamboo advertisers, and love to use new technology. I think we could build something quickly, cheaply, and get a prototype going to see if we have something here.
For example, it needs to have things like:
- A way for the drunk pandas to register, login and logout
- Drunk pandas love drinking, so they’d love a way to find the best drinking places. So you need to be able to enter locations, save locations, rate locations and comment on them
- Drunk pandas love to post photos of themselves at the local pub, so they need a way to upload photos, share photos with friends and delete photos
- Drunk pandas are super friendly, after they’ve had a few beers, so they definitely want to friend other drunk pandas, and share photos only with their friends…
Engineer: “Ok that’s enough for me to go on for now, though I’d love to have some basic wireframes to give me some guidance…”
PM: “No problems, let me quickly spin something up in Balsamiq for these flows (or your wireframing tool of choice), and we can check back in a week to see a demo, sound good?”
Engineer: “Great! I’ll get to work with the team…”
Here’s how it should not go:
PM: “Hey gender/ethnic neutral Engineer, I have a genius idea for a new product: I’m calling it “Bamboo Dreams”, a social network for drunk pandas…..”
Engineer: “Please provide:
- a 50 page slide deck justification of your vision to get approval from senior management (over no less than two years), without which we are not allowed to build anything
- a detailed use case specification that initially will not get read by Engineering, that can be used to blame you when inevitably you forget to tell us something we should be building, at which point they will be read in detail
- full usability tested hi-fi UX design, any deviation from which I will cost at 50 story points per change request
Please note any omissions from these items will result in you being blamed by all of Engineering for idiocy, ignorance and general incompetence at your job as a PM…”
PM: “…….we better not build anything then”
I’d like to say you could extract a few small things from a made-up example like this:
- Rarely, at least in the majority of B2B software, do you have the quantitative justification to embark on a new product or feature (or rather it wouldn’t be worth the effort to get the data).
- Sometimes, innovation is based on gut, instinct and experience. And then trying it.
- If you can’t explain it in one page, it probably means you shouldn’t do it.
- Anyone that asks you for a 50 page slide deck needs their head examined.
The idea that you create a “vision” that you convince others of through your reality distortion field is an urban myth perpetuated by Steve Jobs-like cults.
As a PM, you of course try and base roadmap on as much quantitative evidence as is available, but you rarely know 100% of the time the right path.
That, of course, is a whole product management topic in and of itself.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!