Looking for Project Managers
I’m on the look out for a solid project manager to be a key part of the product management team here at MusicIP.
If you know of anyone, or yourself, has experience charting through multiple SDLCs and in a client-faciing capacity, get in touch. One caveat is that you must be in the LA area.
Time for Help
It’s time for me to get some help.
Ha ha. No, not the white jacket, Lindsay Lohan kinda of help.
But a person to help me manage our existing product portfolio.
I’m starting to realize how drained my time is. And, I suppose, part of getting older is realizing when to put up your hand because you need some time with yourself, your friends, and your family. And start-ups can occupy every waking hour if you let them.
Now, I’m not saying “gee, I really don’t like my job and I want someone to slough stuff off on.”
I love my job. I love being a product manager and the trials and complexities that come with that role.
I also love team building, teaching, learning, and building things with others.
So, I’ll be working this week to build a justification / key points that I can present to the suits (sorry, just watched Entourage tonight) and seeing if I can get a budget to bring in another product manager to be a part of my team.
A large part of wanting this is to ensure that our products succeed and recognizing that I can only focus so much of my time on a certain set of them before burning out and letting them go to the dogs.
I don’t want that to happen. But another person that can actually work with me and learn the market and build cool / great stuff for those customers is very important.
Who’s helping you? I know Bob has made some posts about how he owes his life to his project manager. I’ve seen the light, Bob…
Agile Requirements
I’ve written long requirements documents. Really long. Coupled with vision documents as well.
They suck up a lot of time, and usually, the argument is that they are needed in order to keep people on track.
Well, recently, I’ve been experimenting with agile requirements writing and let me say this: it’s one heck of a lot easier.
I’ve combined a basic requirements table / roadmap along with product definition to create my own PRD-style document. The TOC looks like this:
- Document Overview
- Problem Statement
- Vision
- Market Segments / Target Market
- User Goals
- Requirements
The overview section is pretty boilerplate. I’ll include information regarding the document as well as any overarching requirements themes that I have in it. For example, within a user-based Web application, one requirements theme coul be “user management.”
Aside from that, the other sections that are included are pretty self-explanatory.
The requirements portion though - that’s the difference.
I have all requirements laid out in tables. One table per version currently planned, and the one table at the end of the document for the backlog of functionality that’s important, but not yet assigned to a release.
The table I’m referring to consists of 6 columns:
- ID
- Name
- Description
- Estimate
- Risk
- Notes
Each of these columns play an important role when they are applicable. I say that “when they are applicable,” because not all of them always are. For example, small internal projects need documented requirements, but doing a risk assessment is probably over the top there.
Each row in this table is a “story” by proper definition. And, as most of us should recognize, stories are (in effect) just a more “modern” version of saying requirement. But to be clear, they are not use cases.
Oh, I should stay away from this - I’m verging on religious discussions. Eek!
Now, there is another person in our company working on defining requirements for the first time. When discussing methods to do this, she had a hard time, and felt very overwhelmed with the death-march style of waterfall project management.
And no, the pros / cons of waterfall did not lend well to this project. A more agile approach was highly applicable.
But, the benefit here was, by following this simple structure, she was able to get a great handle on the project / product she’s working to ship quickly and had a much easier time explaining it to others in this format.
I have the same feelings.
Some so straightforward lends itself quite well when needing to get these types of things in front of developers, project managers, QA folks, and writers - all working on the same product.
I’ll post more about this structure / format in the future. Just wanted to get some thoughts down on it this evening.
Competitive Exploits
Our marketing team just put together at fantastic competitive analysis for some top products in a space we are going to be aggressively pursuing. The major thing I look for in a competitive analysis is how easy it is for me to extract exploits.
I need to be able to read through the analysis, no matter what the format is, and be able to say, “competitor A doesn’t do x, y, and z as well as we do” for each company in the block. There are a multitude of different ways more deeper analysis and strategic planning can be completed (read: SWOTs), but, for time-sensitive stuff where you want the data and it needs to make it easy to verify market data and allow you to find weaknesses in what’s already out there, that’s what rocks.
There isn’t a specific art to it either. In order to do it correctly and well, you must be intimately familiar with your not only the core competencies of your product, but also your company as a whole.
Really, all you want to do is jot down bullet points that are geared towards getting some cross-functional folks (namely product mgmt and marketing) on board with making sure the messaging to clear, and functionality is clear when applicable, to win over the existing user’s of product’s that are probably feeling the pain of using them.
How are you working to find out how your products can solve the pain of your user’s better than your competitors?
