I’ve been a bit hard on product managers these days on old geekypeek. A confession, I have been a product manager for more of my life than I have been a developer, I’ve even led large product management teams.
In the world of a startup, the product manager’s role is always a bit interesting. The first startup I worked at, Redknee, the product management role was basically “everything that a coder doesn’t do”, which was centralized around talking to the customer. We were a B2B teleco billing/customer care software company. So I’d spend a lot of time preparing documents for customers and writing documents for the dev team to ensure we built the software per the customer’s needs. We also did a lot of things like system design, testing, writing manuals, sales support, etc.
Traditionally, there is the holy triumvirate of product management skills, per some pdma spec somewhere:
-technical product manager -> writes requirements, project manages development
-marketing product manager -> how to market this thing best, market research, etc
-business product manager -> p&l, how do we make money
But in talking to other companies I most often see product managers doing this:
-writing requirements/functional specs
-project managing dev’t
-UX/UI design
-QA/UAT
If you are a product manager, and you find your self spending most of your time on the above, I think you are ultimately negatively contributing. I’ll first explain why I don’t think you should be doing the above list, and then I will comment on where I think product managers in a startup or lean dev team should be.
Writing Requirements
My first problem with requirements is temporality. Most requirements docs are valid for 3-5 days. Then everything changes. Eventually keeping the now lengthy requirement doc takes as much time as making the code change, and it becomes another mental hurdle that will in fact slow your dev process.
My second problem is that 93% of requirements are damn obvious. Writing them out was a complete waste of your time. The other 7% are hard enough that there should probably be a discussion between the whole project team (the developer, the customer care person, the finance guy, etc). Unfortunately the habit of writing a “requirements doc” is that a product manager writes it in detail and then presents it as the truth. Good product managers who are trying to figure out what the product needs to do, need to be collaborative in their process as the whole team will need to input on the very tough requirement decisions. Annoyingly then, since there was a meeting to discuss the 7% of difficult requirements, formal documentation isn’t really required.
Finally, from the moment development completes you have three very readable sources to understand how a product works:
1. The product itself. It should be intuitive that somebody can figure out all the features in the first place. I shouldn’t need a requirements spec. If you have a long requirements spec and an unusable product, you have failed as a product manager (and so has the dev’t team)… monumentally.
2. The code. Code needs to be human readable, even by non-coders.
3. User manual.
You really don’t need a 4th document full of shalls and wills that states what the product does, on top of the above.
Project Managing Dev’t
Tools will do a better job than you can. Using the following tools its possible for anybody in the company to readily grasp status:
1. A build server with daily/nightly builds
2. Automated communication on check-ins of changes (e.g. an email to all of every check-in)
3. A project site – basecamp, wiki, sharepoint, etc
4. Project mgmt software with bugs and tasks – I love pivotal tracker.
5. Automated testing with your build/check-in process so you can see test case coverage.
6. Working product – having something bare bones usable so anybody can try it out and see where its really at.
These tools will communicate status more accurately than you, and prevent large time sinks for issue burndowns, bug scrubs, etc. To this day, most business folks don’t realize that development is an extremely complex cognitive task that requires a long ramp-up time to get productive. You should not interrupt a developer in mid-development/bug check-in to get a simple status update that is retrievable from a bazillion sources.
UX/UI Design
If you were a startup, and you had your choice between a UI/UX designer and a product manager, I would push you strongly towards the earlier. Most of the tough requirements around a product are in usability. Feature/complexity tradeoffs with usability. An experienced UI/UX professional will bring a lot more to the table than your average generalist, former engineer product manager in this regard. Not only should they understand how people use interfaces, they should be able to create the graphic design for you, and understand the testing process of that UI/UX. Or spend the money you’d spend on a product manager on a UI/UX shop. Too often I see product managers espousing usability views that really should have been left to the professionals. Or if you do use a UI/UX shop, the product manager ends up being the main contact for them, which in turn means the UI/UX shop & developer never have enough conversations about what is needed vs what is doable.
QA/UAT
There are several types of tests, I’ll stick to these three:
-functional testing
-End-to-end/UAT
-usability testing
-beta testing
Coders need to automate functional testing. Unit tests should be comprehensive enough that they are confident that the system will work. They also need to run “unit tests” on the system level. If you are a running a website, there should be screen scrape style tests using htmlunit, watir, cucumber, and that type of technology. There should be an extremely high level of confidence shown through test coverage reports.
Ideally there is no need for “end-to-end” testing/UAT. If following an iterative, agile process you will have been using more and more of the product each week. Everybody in the company, especially if you are in launch mode, will have been using the product and providing tons of feedback. So the big-bang UAT isn’t needed.
BUT… if you are a startup and launching a major product, its probably worth thinking about doing a big final round of testing. I’ll call this business simulation. Lots of fully end-to-end testing. For instance ordering the device from Amazon, paying using a real credit card, using a paid for/ordered device, phoning real customer care for issues, using real FAQs. This is less about “functional” testing then it is about “business simulation”.
You will also probably want to be doing a beta-test during this period and getting real customer feedback. Real customer feedback is important. In fact, one problem I have with UATs is that it slows down the feedback loop to real true customers and sometimes beta is even skipped!!! No – beta is probably your most important test. You should be finding ways to get real customers to use the product as early as possible. Its the closest you’ll come to the real thing.
So, while I am advocating that product management is not needed to do the above, if you are in “launch mode”, or a major product release, you may need a generalist person to govern this whole process, and that person may feel/look like a product manager. Somebody needs to ship units to beta testers, tell people what to test when, collect feedback from beta testers, organize their thoughts and figure out what isn’t working, etc. My favourite startup/launch idea here is to use the person who will manage care/support as that person.
If you are launched and doing frequent smaller revisions you do not need a full-time body here. You can compile a list of beta-testers and basically automate new releases and communication to them. Or grey-launch to small groups of real users.
Where the Product Manager Should Be
All along, you may have been reading and thinking I am anti-product management in the start-up. Well, thats not completely true. In the world of startups, here is where I think the product manager needs to lie.
You launched. You probably got all of the following wrong:
1. Channel
2. Price
3. Target customer
4. Feature line-up to customer
5. Your whole value prop
Turns out beta-tests and market studies are nowhere near as truthful as actually selling the damn thing.
Your first few months as a startup are all about “finding the business model”. You need to figure out who your customer is really, really, really quickly… because you are also probably burning cash on all your ace developers (their 3 monitors each, their $1000 chairs, etc) and running out of funding. Once you know who the customer is you then need to pivot really quickly as an organization and figure out:
1. How to acquire those customer cheaply
2. How to best-fit the product to those customers
3. Value prop for those customers
This probably should be the role of the CEO and VP Marketing. But it depends on your financing model and who does what in your company. Your CEO may need to be full-time raising money either through financing or sales. Your VP Marketing may also be full-time selling and trying to maximize the current strategy/marketing plan. You are never sure if the whole strategy is off (i.e. wrong customer, channel, etc) or if you are simply not executing to it. So your VP Marketing needs to be executing his brains out on the current plan (SEO, SEM, meetings with retail, partnerships, media, PR, trade shows, etc), which may mean they don’t have time to come up for air and take a look at the broader picture.
So I love a product manager that does all the deep innovation stuff to really learn the customer. Stuff you hear that P&G does –
1. Follow/survey shoppers in the store/online to see how and why they buy
2. Shadow customers and learn how they use the product
3. Survey the base constantly to learn who is using the product and how
4. Survey people who returned the product or took a trial and did not move forward
5. Survey people who didn’t buy the product (non-consumers)
6. Take care phone calls to get qualitative feedback from users
All that data needs to be gathered fast and then used as the genesis for either making minor tactical changes in the current strategy, or making a whole sale strategy change.
Knowing you customer is probably a more investable lever than “cool technology”. If you are an expert on some niche customer base that you have discovered is a great user of your product, you are building massive value that somebody else will want/need.
And thats where I’d like the product manager to be, customer centric and connecting the value prop with the customer. And annoyingly its really rare that I see the product manager in that spot.
—————————————————–
Buy the new Peek with the hot new 1.10 software!
