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.
Product Management Career Path
I have a new question / post up at Ask a Good Product Manager - answering, “What is the best product management career path?”
What Are Good Requirements?
What makes a good requirement?
That’s something that is completely open to interpretation. In my humble opinion, a good requirement is one that is clear and direct. It communicates what it is supposed to and then moves on.
No muss, no fuss.
There are many out there that will disagree with me on this. That’s OK - it’s all open to interpretation and what you’ve seen work before, or have tried, have succeeded with, have failed at, etc…
See to me, in the scenarios where development is not run by product (which should be every scenario if you want to do things right) you need to have a good partnership there. If that doesn’t exist, things will go down the tubes pretty quickly. That being said, you don’t have to love each other and hold hands - but something has to be shipped.
Now, to boil this down pretty quickly, I really see there being only two types of requirements:
1. Agile requirements; and
2. Waterfall requirements
These are really polar opposites of one another. You can’t get much different, aside from the fact that you are communicating the same problem you want solved within each - they are both just different ways to communicate them.
The thing I have come to realize is that for agile to work - for it to really work - you need everyone behind it and you need pretty smart developers who are on the ball. The main reason for this is that you want great code to be written, but the time you are saving by not writing long (and I mean looong) requirements documents produces ambiguity, and that must be filled in by the developer as they go.
They must ask questions. They must talk to you (the product wonk). And above all, you must trust each other.
Some developers have serious issues working this way - I get it. I understand it’s not easy. It puts a lot of onus on those that are writing the code, as opposed to the waterfall way….
Now in waterfall, at least in my experience, you are pushing away communication in favor of documentation. Developers want every single piece of a feature mocked-up, written down, and worked out before they even start thinking about the code. I always picture this style of process as taking things and lobbing them over walls. Requirements over a wall to dev, code over a wall to QA, QA over a wall to production, etc, etc…
Especially if your team is small, working this way is not leveraging one of the team’s crucial strengths - it’s size.
A lot of companies work in waterfall, and it does have its place. Specifically in organizations that demand a heavy process workflow through a release - or something that has a ton of formal check points. Two examples here (respectively) could be a bank and a consultancy
If you are going gangbusters trying to get products out the door, the last thing you need are formal check points. The last thing you need are 50-100+ page requirements documents. But that is what happens. This gums up the works for several key reasons.
The main one is, people stop talking. They stop asking questions. They just assume they can blindly follow the documentation - and if it doesn’t turn out right, oh well - wasn’t documented that way, so it’s becomes a bug. People way smarter than me came up with the agile manifesto for a reason. It can and does work.
People are smarter than this and everyone should expect them to be.
Of course developers need things to go on. You can’t expect them to read your mind and they can’t design anything (in most cases). But they are smart. After all, they are computer programmers.
The bottom line is this - no one can tell the future. As features get implemented, they change. Sure you know a lot of things up-front (button goes here, text goes there, save this, etc…) but you are 100% bound to miss things. If your product release process doesn’t account for things being missed down stream, it’s wrong.
Remember one of the key tenets of agile - put things off as long as possible until the last possible moment you can decide to ensure you have the best set of information at hand to make that decision.
Those things don’t happen in closed-door offices with a product manager huddled over his keyboard typing out requirements and acceptance criteria fast and furious. They happen in talking to those coding out those ideas and breathing life in to them.
But, not all teams are cut out for that sort of challenge. And that’s OK too - just make sure your management team knows you are going to need a solid chunk of time (1 1/2-2 months) per release cycle. And make sure you have some spare toner and paper ready for your printer. You’re going to be doing a lot of editing on those requirements docs.
Book: Tuned In
I got my copy of Tuned In sent to me today from Amazon courtesy of the publishers / authors. I found out, by way of chance, that I’m acknowledged in the book. I hope that whatever it was I was acknowledge for was insightful and deep.
Because, let’s me honest, I know it was for my post comparing product management to movie directors (using Kevin Smith as the core example) and my post calling out Tony Stark as one of the best technology founders to date.
But to be honest, it’s pretty cool to see your name and URL in print. I’ve been writing on this blog for a long time and hopefully I’ll be able to rally enough folks that listen to me go on and on about things regularly to write our own book on product management.
I haven’t read Tuned In yet but it’s getting some great reviews on Amazon - so kudos to everyone that took part!
Product Management Wiki
As suggested, I setup a wiki:
http://productmgmt.wetpaint.com/
If you would like to be a member / edit the pages, send me an e-mail and I’ll get you the information.
I just have the basics there based on my manifesto post and I would love to see it evolve / grow / tweaked / etc…
