Growing
Short post — but just an observation too long for Twitter.
You know what’s better than actually pushing an initial product out the door after its inception? Watching it grow — the actual “management” part of product management. This is where you learn how users react to it, and where you see the market inputs you’ve setup start to fill up with ideas and opportunities.
And when you start to see common themes across different inputs you have setup, that’s when you know you are going in the right direction.
There will always be critics and naysayers. And you can always get better.
You will always need to enhance, tweak — and generally make things better.
That’s the fun part of product management to me, because it’s when you see the whole product really start to come together. At least in Web start-ups, at the beginning, cross-functional teams are very loosely defined and may (or may not) really know how to work together.
But as you fight the battles, and take the wins and the losses with one another, that’s when you all start to build a product that’s really awesome.
I’m in the early days of this stage of a product right now (moving away from the introductory cycles and in to the growth stages, where the stakes are higher).
The business will transition along with the product (if the product is the business, which is common in start-ups) and you need to learn to roll with it.
It’s never perfect. It’s never done. Things always need to change and get better; just so long as you maintain focus and have the confidence you are moving in the right direction (and keep everyone informed and open to receiving input) you are doing all that you can to grow that product in the right direction.
Being Too Corporate
When did being a product manager get so corporate?
Maybe it’s just me — it’s entirely possible. I have been called “corporate” myself in the past. But I like to think I have finally learned the time and place for process, sign-offs, meetings, and things of that ilk. Sure, I still get it wrong from time to time, but I’m much better than when I first started out in the crazy world of start-ups.
I was under the impression that everything should be, and needed to be done like big business. Mission statements, core values, strategies, balanced scorecards, executive management, titles, retreats and off-sites. The list goes on and on.
Most of that stuff now makes me think, “um, ew.”
Now don’t get the wrong idea. Much of that stuff does have merit - there is just a time and a place.
I think I started to realize a lot of this by reading some Peter Drucker. Funny enough, right? Since you typically hear the big corporate dudes talking about him and his writings. But there are some really important lessons that apply.
See, start-ups tend to get really starry-eyed about things that have good intentions. The biggest? Revenue / money.
Before you jump all over my case - of course revenue is important. Of course it is. Profit, cash flow, NPV, etc — it’s all important to running a successful business. But it can’t be the reason a business exists. You can’t exist to make money. If you do, you have shot yourself in the foot.
See, some start-up people fall under this spell - that they refuse to do all the corporate-speak, and they are adamant the only reason they are there is the make money hand over fist. I used to be that way. What else is more important, right? Don’t people join start-ups for the promise of the big pot of golf at the end of the rainbow?
And aren’t all these fancy things needed to get there? Won’t you fail if you don’t do off-sites, and create strategy documents, and have process on top of process?
Just like a company existing just to make money, you can’t get things done a certain way just to do them a certain way. You have to use critical paths. Get shit done. Get results.
That’s what Drucker is all about.
I’m rambling a bit here; I have all these thoughts going on in my head right now.
Do product managers live in a world where they think it’s necessary to put together 60+ page analysis documents before writing a single requirement? What about studying where your organization is inside of a market quadrant before anything is actually coded? How about modeling the entire business before you’ve even define what the product will be?
Don’t put the cart before the horse. Falling in to that lull is super-nasty. It creates black holes in the business, and in start-up land that will prevent you from getting the most important thing - results.
I know how nice it feels to have resource loading charts, and air tight development methodologies, and cross-functional charters. It feels warm and fuzzy - and gives a false sense of reality. You aren’t actually getting any results with these things. You are just putting off the inevitable.
Everyone has to talk, everyone has to work together. That’s why small companies are just that - and can do the things big companies can’t. Produce the same results a 10,000 person organization would take 2-18 moths to do in less than 1 week.
Why? Because no one should be concerned with getting 10 levels of sign-off, or finishing their interpretation of how the business fits in to Porter’s Five Forces. Who Cares? There is plenty of time for that stuff later. Just worry about shipping the release and getting feedback.
You should be starving for feedback. You should not be able to get enough. You should be finding the ways to make it easy to discuss that feedback and prioritize it - so everyone stays on the same page.
But don’t worry about arduous documentation - just write it down. Don’t worry about sign-off - just have a conversation with someone and ask, “does this look good? yeah, OK - let’s do it.” Don’t exist to make money.
Just get some results.
Watch for Flags
Having done a few start-ups and having some interesting experiences (OK, very interesting experiences) along the way, there are a few red flags I keep my eyes peeled for.
Your mileage may vary, and I’m totally not trying to hit all of them here - just some stuff I’ve learned to watch for in the past, and I thought I’d jot them down.
Requirement Delivery Time
In product management, there is a pretty big flag that I keep my eye on regularly — time to deliver requirements per release. If you are looking at regular 4-6 week requirement cycles, you are going to hit a wall.
Maybe not in the current cycle. Or the next. But eventually - especially with the lack of resources on hand.
Big companies can get away with this because they have entire teams dedicated to writing and analyzing those requirements and the process with which they are derived and developed.
However, in a team of 15-30 people, you should be more worried about getting priorities full working…not written down to the point you have to use a dolly to carry those documents between your desk and the desk of your project manager.
Silos Between Groups
The road to hell is paved with good intentions. That’s how I’d describe silos.
There is a weird start-up dichotomy, which is folks need to make-up for the lack of certain roles that aren’t in a budget, but they also must do their job. It’s so nice and sugary sweet to think that everyone is a generalist that can step-up and help rally the troops wherever they are needed.
These people are very few and far between - and really have their limits.
But, on the flip side of this is “everyone must do their job.” There is a misconception that stepping out of that boundary can cause a lot of tension due to toe-stepping.
It really lies somewhere in between.
Things cannot be lobbed from one group to the other without communication. That’s a really, really bad sign. The thing to watch for to determine if silos are in fact forming is communication and involvement.
You should be talking to everyone regularly, and they should be talking to you. That’s not to say you should be having all-hands meetings every week or having everyone reading each other’s e-mail.
Let’s not get crazy.
But, that is to say in order to work together you have to have trust and the right steps must be taken in order to build that relationship so it’s down right effective. Silos are nasty buggers that can also lead to culture shifts (described below) and one of my all-time favorites (not!)…turf wars.
Culture Shifts
In some cases, people can cause culture shifts. They don’t happen overnight, but they do happen - and when they do (and they are negative) they are extremely taxing on the business and very difficult to repair.
While the CEO should be watching for these regularly, they don’t always have the option of seeing every little thing in the field, so it’s great to recognize when they do rear-up to have a chat with those that need to have them called out.
Doing so, and learning to spot these suckers early, can ease a lot of stress and tension and severely dropped morale later down the road.
Will to Act
Everyone must be willing to take action to get things done. Too often people can become paralyzed by the notion that things are really hard, eat up their time, and cause them to be frustrated.
Now, of course people spending 24 hours a day at the office is bad. But the odd time, there are required pushes where people will work overtime in a start-up — because that’s how things go.
Everything in a smaller company can tend to be hyper-amplified in many different ways, making them appear really out of reach or frustrating. Some times, the only way to move past this is to a) recognize there is a problem b) determine the solution and c) execute.
It’s crucial that things don’t stagnate or stop moving forward - that’s when there is a serious issue at hand.
What To Do
Learn to spot these bad boys early and often. Learn that you don’t know everything and that your instinct could be off but 9/10 it’s way better to be safe (and have a discussion about this stuff early) than sorry (i.e., trying to explain to your higher-ups why you didn’t call this to their attention sooner).
Maybe your wrong - maybe your crazy. But chances are, if you’ve seen the movie a couple of times before, you have a good enough understanding of these types of things to know when to call a spade a spade and bring it up.
Giving Effective Feedback
I’ve seen several posts written, and written several myself, about gathering effective feedback when you are in product management. But what about everyone else that’s interfacing with product? How can you give PdMs good, solid feedback on a consistent basis?
First, lets take a quick step back - why do we encourage anyone and everyone to give feedback? Isn’t it the PdM’s job to identify the ways to make the product better?
it’s true that one of the core tasks of product managers is to gather and filter input, make decisions based on it and/or make recommendations to senior management about directions to take or priorities to pay attention to. But, there’s one important thing that everyone in an organization should always remember - it’s everyone’s job, all the time, to help make products the best they can be.
Many PMs will tell you that they’d rather receive what someone thinks to be a crappy idea than no ideas at all. Ensure there is in fact a reason for the suggestion and it does provide value - or, at least, you think it does.
I will always try to ask, “what do you recommend?” (or more simply, “why?”) when receiving ideas / notes / feedback to ensure I’m capturing the full thought, and that one is actually there. I want to be sure I get an entire notion or idea - not just cut it off and only take a potentially negative criticism. If a PM in your organization is blindly accepting things like, “this doesn’t work” or “I don’t like this,” they aren’t doing their job.
They need to dig deeper to get the entire request. This is why it’s important people interacting on the front lines (with real users) are trained to inquire and gather that feedback properly. Many times, users will just write a 1/2 finished idea without even realizing it. They may written at a time of frustration or being super happy while using the product; but in many cases they will leave off the “why?”
The “why?” is the most crucial part, because it’s what tells product manager’s what’s actually important to the user giving you the request. If that’s not there, it’s all very binary - a thumb’s up or down would suffice.
This doesn’t just go for product feedback, but delivering feedback in general; especially when managing others. One of the best lessons to help someone that may be more junior (or, depending on how you look at things - less jaded) learn is how to deliver proper feedback. Whether that’s a product idea, making a PowerPoint deck look better, etc… The earlier people get comfortable with the practice of actually explaining why they are saying something, the better. But, I digress.
Product manager’s should always be willing to listen to feedback. And those that want to provide it to them should make sure they have these critical elements in their delivery. Heck, anyone should feel comfortable even asking their PdM if they are providing their ideas to them in the most effective way possible. That should help clear any confusion / misinterpretations up pretty quickly.
Tony Stark - Best Product Manager Ever?
It’s not a secret I like Iron Man. Even if that now, in the Marvel universe, Tony Stark is a total ass.
With that being said, I think it’s pretty clear that Tony Stark is probably one of the best product managers technology-focused founders ever.
Update: See the comment thread with Bob Corrigan of ack/nak fame for the reason why I changed this. He’s totally right…but Stark still gives one hell of a demo.
Nevermind being a successful founder of a huge military-driven organization, but he’s at the centre of all of the products the organization creates and releases to their customers and the market(s) they occupy. While there are flashes / glances of this throughout the comics, it’s pretty defined within the movie. Obviously, I’m leaving aside how crazy that is for the size of company Stark is supposed to be. But, I digress.
If I could link to specific clips I would. However, I will say this - Stark’s product demo skills are unmatched. Here’s his pitch for a new product (a missile, called the Jericho).
*They* say that the best weapon is the one you never have to fire. I respectfully disagree. I prefer the weapon you only have to fire once. That’s how Dad did it, that’s how America does it… and it’s worked out pretty well so far. I present to you the newest in Stark Industries’ Freedom line. Find an excuse to let one of these off the chain, and I personally guarantee, the bad guys won’t even wanna come out of their caves. Ladies and gentlemen, for your consideration… the Jericho.
Stark is every VC’s dream - he is both business savvy and incredibly technically savvy; not a lot unlike Bill Gates.
I’m sure Stark Industries / Enterprise / International (the name depends on where you are in the comic timeline) has seen some pretty brutal product and technical reviews go down in their halls - with engineers either out of jobs of reduced to tears after having Stark rip apart product specifications they have created.
Of course, I’m stretching things a bit here. What am I really trying to say? That an organization needs a Tony Stark in order to truly succeed? Of course not.
But, he does the same thing as any organization ever has in order to make it truly successful. He didn’t start out with all the crazy technology he currently has and billions of dollars. He started out being obsessed with building the best military weapons possible. That’s the point.
Google did the same thing. They didn’t start with Gmail, and Google Gears, and Picasa, and all that stuff. They started with search. They got that right, have billions of dollars today and a myriad of products. But…guess what?
They picked 1 thing (search), obsessed over it, and got it right. Then they made things more complex, and grew, etc… But they didn’t start out with the goal of being a billion dollar, 16,000 person organization.
Just like Stark obsesses over creating the best weapons technology around, products can only be successful if they start with 1 champion (a founder, CEO, product manager, etc…) and it solves a problem, and it’s obsessed over, ultimately by a group of people working to achieve a common set of goals.
