Focus and Vision
The title of this post is so reflective of two key things that are necessary for success. But there are definitely some others. Leadership. And another biggie - making and committing to bets.
In order to really drive a company forward, it needs to have a vision. Say what you will about buzzwords, this is really important, because with a lack of vision, you really do have a bunch of people wandering around wondering what on Earth to do, and how they fit in.
But vision isn’t the only thing.
You need to provide the team / company with the open-area, big room ability to stay focused. They need to have flexibility to respond to the customers and the market, but don’t fire off so many projects that they can’t be effectively managed, and “crap” starts to squeak through the release door because people aren’t paying enough attention to the right things.
Make a bet. Base it on the vision. And the drive that thing to execute. Get the team rallied behind it, and put out quality product.
And when you get a team working all on the same goal (releasing a product for a specific purpose), it’s a beautiful thing to watch everyone react when it’s a success. No kidding.
But where does it all start? Defining vision based on an identified problem and market. This isn’t news here. I’ve been preaching this stuff for a while — all the way back to my Party of Four model.
If you don’t have that excitement going yet around a focused, crystal clear vision, get one going. Foster not only creativity and innovation and market attention, but also quality in your products and what you’re putting out the door.
Water Falls Away
So, after getting back from an unanticipated extended vacation in Toronto, started updated all of our product planning. I got everything back to the way I thought it should be.
And then it hit me when I saw this line come through from my CTO:
“We’re waiting on requirements”
…this in relation to a new product launch we’re working on. I have been mortified ever since reading that. On the way to a great weekend in Dallas with friends, I spent the entire 2 1/2 hour plane ride from LAX to DFW thinking, “how can I stop this from happening again?”
Each time I started thinking through us developing in an agile-like environment, I would hit a wall of, “and then we move into product design.” Wait. We don’t have any design expertise in-house. Or even externally that we can call upon.
But then, the next day, I received an e-mail from our lead VC asking me to phone interview…wait for it…a usability expert. So sweet. Perfect. Plants align. Let’s see if this person can help - keep your fingers crossed, folks.
OK, so now what? Well, we are working on a couple of big things at the present time — as I mentioned, a new product launch, but also, a big upgrade (of sorts) to an existing product. That project has one of our senior-level developers attached. So what did I spend some hours working on this weekend?
Taking what I had started as a waterfall-style requirements document and turning it into user stories. Yes, sir. Here we go.
Now, the beauty of this scenario is, everyone at the company is currently amp’d on getting user feedback before releasing. Mission accomplished there. So, what I’m embarking upon isn’t an “overnight change to proper agile methodologies.” No, no.
We are already doing agile-style stuff. But what’s the next piece of the puzzle? Putting trust in the developer’s hands to be accountable to working through details. And, pushing more estimates and risk assessments through dev.
Now, we won’t get to assessing risk right away. I also won’t be graphing up project velocity tomorrow either. The name of the game is, “here are the stories, work with the product designer on the UI, and we’re all going to meet (technical writer, QA, dev, product, design) every day for 1/2 hour after lunch to discuss what’s been done in the last day, and what will be done in the next day.”
This also helps to move away from a structure that gave me major headaches while trying it push out another product revision. The developer lost track of requirements, I wasn’t keeping tabs on the development status well enough, and folks were being brought into the project at waterfall-style times.
It’s like we were trying to do agile stuff, but forcing those pieces into waterfall-like structure. Yuck!
But I think I’ve figured it out. But like I said, I recognize that it won’t be an overnight change - it will take time. And will we follow an agile methodology to a tee? No way. But, after living and breathing our development for over a year now, and learning and growing more as a product manager, I now see how valuable some of those practices are for us as a team.
And hopefully, it will keep our CEO happy. He loves to see product ship - and see product ship that’s going to help us accomplish our financial goals. So, with quick reactivity to the market / and FOI (”flashes of innovation”), we’ll be able to speed up dev, but speed it up responsibly.
I don’t know why I slipped back into waterfall-style thinking. But I’d like to thank Jeff Lash for breaking me out of it. We had exchanged a couple of e-mails last week, and a couple of things he said broke me out of that. Thanks, Jeff.
Effective Product Marketing
Ever have one of those days where things feel like they fit into place? Well, I’ve had several of the last couple of weeks. And it’s all thanks to product marketing.
I don’t pretend that I’m a marketing guy. Yeah, I get the concepts. I understand the fundamentals well enough to converse and help out with strategic activities, but it’s not my bread and butter. Now, if you are lucky enough to get solid marketing folks into your organization, and your organization is software, I encourage you to read up on the interaction between product marketing management and product management.
Let me help by saying this: they are not the same thing. Software product manager’s, unless they are explicitly focused on marketing, should not try to take the reigns here.
Wikipedia has a great article on product marketing, even with a section explaining this. The biggest favor you can do for yourself it to get folks on board with the idea that product marketing plays the biggest role in gathering the feedback.
Yeah, I get it. I wrote a pretty up-front article on Sales running development. Now, I still believe that this is a bad idea, with a couple of lightweight exceptions. Those lightweight exceptions, funny enough, roll right into providing market feedback.
This is where it becomes so clear where MRDs and PRDs start factoring in. Marketing takes the lead on the marketing requirements document, while product management takes the lead on the product requirements document, with each group meeting somewhere in the middle to ensure the key components of each thing remain clear.
At least, that’s how I see it. And it’s become quite clear to me how valuable solid product marketing efforts are.
Welcome to Spidey
For this weekend only, to coincide with the opening Spider-Man 3, I’ll be wearing my superhero colors proudly with this theme.
I am a huge fan of Spider-Man, and will be one of the geeks lined up for the 12:01am showing tonight. I hope everyone will go check it out this weekend, and gets a kick out of the new movie starring my favorite superhero of all time.
Your Friendly Neighborhood Product Manager,
–Adam
Sales Driving Development
I never thought I’d type the words I just have in my title. But I did. Why is that?
Well, surprisingly, this still happens today - and more often than we PM’s would like to think. What’s even more surprising is how everyone thinks and knows this is a bad plan, but still lets it go on.
I’ll see how clear I can make this for everyone. Folks that are actively selling should not be responsible for driving or managing product requirements and shipping things. I’ve been there, and been bit in the ass, and boy…it hurts.
I feel as though I need to get in some theory here, because I want people - whenever they think it’s a good idea to do this - to come to this post, slap their forehead’s and say, “yes! now i remember why that’s a no-no!”
First off, why do people think this is a good plan? It’s simple, really. But even before that explanation, what causes this issue?
Everyone (well, most people anyway) agree that market-driven products with touches of internal innovation are a good idea. “Listen to the market!” is rhetoric that many people spout off and hear daily. Sadly, it very rarely means anything. Companies must commit to this, and actually make sure people know that their opinion (unless backed by verifiable customer data) counts for little to nothing at all.
Now, back to why folks think this is a good idea. Isn’t it clear? Skip the intermediary. Why have a middle man gathering feedback? Just have Sales give their feedback and work directly with Development. It’s way more efficient than having someone sit there, aggregate data into a spreadsheet / list-type format and than write requirements around it.
Ummm. Doesn’t work. Let’s examine why.
Folks in Sales should only care about 1 thing: selling. Bringing in money. Their commission checks, and the size of said checks. How does this conflict with proactive and well-planned products? Hmmmm….
If you were on the brink of closing a deal, would you care about the most effective way that the market would benefit from a feature? No, no. You’d care more about the way the customer ready to write you a check will benefit from a feature. Or maybe how the customer after that one who’s going write you a fatter check will benefit from that feature, or a different feature (or 2 or 3).
If a Sales person doesn’t care about that, they should re-think being in sales. I expect it now, and it’s why getting Sales involved in product development is typically a bad call. Because if they could just get that 1 extra feature, they could sell 1 billion dollars of product by the end of Q3! After all, they have 500 prospects all lined up, ready to buy. Barf.
This is why product management sits between what I like to call the “market faucets” (Sales, analyst reports, etc… - IE, all the points of entry for market data itself) and development / getting the product shipped. They are there to aggregate and make sense of all the incoming stuff. They are there to say “no.” In fact, I did so the other day. Got on a conference call, prospect asked for a feature at 10:03am, I said “no - don’t have it now, not on our roadmap,” prospect thanked me for my time, we were off the call at 10:05am. I had logged the request in my spreadsheet of market data by 10:06am, and I was on to other things. Hard? Not really. Beneficial? In spades.
Think about it this way. Sales-driven products tend to end-up being very un-focused and jagged. 1 person asks for something, and Sales will put it in. Why? To close their deal. That’s what they are there to do. Not to act as traffic control around all the data coming in. That’s the job of product. In essence, not directly related to closing deals and bringing in money.
If it is, every feature will appear to be proactive. Then you get products that don’t really solve anyone’s problem - they just exist (and bloat) and try to solve every problem. Before you know it, Sales has caused their own pipeline to be shut down because the thing is unusable and needs to be re-thought and re-factored. Extreme? Maybe. But I’ve seen it happen, and so have a million others out there.
