Hi there,
Thank you for your interest! Some time ago I have retired this blog and started a new one. Check it out at startupmusings.com.


Lately I have been reflecting on the role of product management in a startup environment versus a mature company.

My personal trajectory is long on startup and short on other types of companies.   Generally I tend to get involved with companies that have proved their technology with a first product launch.  The PM role becomes formalized in the startup some time during the tricky transformation process of leaving the research lab era behind and entering the brave new world of product development with revenue expectations.  There is generally a bit of a culture shift, and the PM brings value by inserting processes judiciously and helping to shift the mindset of the company to focus on what the market wants, rather than what the technical team wants to invent.

In a 30-person startup, there is often only 1 PM who watches over all of the product lines for that company.  For example, I am watching over 1 hardware and 3 software products right now, with 2 more in the works.  The PM does everything from product strategy and roadmapping to nitty gritty functional specification development, feature list management and bug reviews and what-not.  Often the PM ends up doing some or all of the company’s product marketing management on top of product management.   The PM tends to be an individual contributor, occupying a mature role in a young company.

What does that mean to the work content for the product manager, when compared with a PM in a much more established and mature company?  I have to imagine that the average PM at a startup enjoys more breadth and less depth than the same PM working at an established company.  A startup is a great ride, since one gets to work at every level and own all the products and product strategy for a company.  But one’s time is finite and at the end of the day, there is a lot less time to devote to each product and sometimes not enough time to step back and think strategically about the product roadmap.

On the other hand, a PM at an established company probably would be much better equipped to focus on fewer products and achieve a depth of understanding of their products that would be difficult to achieve with a larger number of products.  I have to imagine the quality of each deliverable would probably be higher.  Also, the PM probably would be adapting themselves to a pre-existing product development process, rather than having to bring their own processes and tools to the startup and improvise quite a bit to suit the needs of the technical team.

I’ve never really been on the established company side of the equation. I wonder if my hypotheses are correct?

Add to Twitter

I’ve been looking for a cost-effective, product management related event to attend for some time.  I came across the Product Camp NYC.

There was actually a Product Camp in my home town earlier in the year that I had wanted to go to, but had missed due to a conflict with another business trip.   I realized PCampNYC was on a Saturday in July, and I have no conflict that weekend.  Plus I LOVE spending time in NYC.  So I went ahead and registered.  In a moment of over confidence, I also signed up to present or moderate a session on primary and secondary customer research.

Weeell… Maybe I should have done my homework before being so very brave!  I got an email from the organizer today with instructions on how to get my presentation ready for PCamp.  So:

1) I should make a presentation with 5-10 slides. (No worries.  I can do this if I have time.  Hmmm.  When would I find the time?)

2) I should post my presentation on Brainshark and add a voiceover. (Uh oh, everyone will know that I am a fresh-off-the-boat immigrant from my accent.)

3) I should upload the title of my presentation to the wiki. (This is where I start to feel really underequipped. I take a look at who else is presenting… and there are all these REALLY BIG NAMES in product management all doing presentations!)

At this point the story of the chicken and the pig came up in my head. I’m the PIG! I’m COMMITTED!  I think I am in over my head!  I can’t see myself presenting anything that’s worth listening to next to these people whose blogs I follow avidly…!

Weeell… I suppose this is what an unconference is about – it’s about user generated content, however inadequate the content might be.   I’m still going to go for it and let natural selection run its course. The odds are virtually nil I will get a slot to present next to these awesome personalities.  They are basically celebrities in my world.  If I do get to present, I will probably embarrass myself to the death.  But at least I would have tried 🙂

I’ve been drowned with several products releasing at once while defining several more new releases (one of which is a brand new product, never done before).   So perhaps I can be forgiven for feeling loopy.   I followed the CPM’s lead and wrote some Haikus on my recent experience with running a Beta program (which started with an in person kickoff, where the subject was taped while they go through the out-of-box experience).

Out of box experience, take 1

beta subject scowls
flummoxed by setup process
user guide no help

Out of box experience, take 2 (after we hastily added a pictorial Tutorial on first run)

beta subject grins
set up product by himself
user guide untouched

On user guides

Seven pages long
Thousands in translation costs
Wasted on blind eyes

Product Manuals

Just read this post on product manuals: <http://effectivus.com/2009/03/the-joy-of-product-manuals/> – thanks to the Productologist for the link: <http://www.theproductologist.com/index.php/2009/04/03/product-management-reader-3apr09/>

I was totally having flashbacks on this.   I’ve personally penned a user manual countless times.   I’ve also written the original draft for all our in-app help text, as well as most of the knowledge base articles.  But I am a product person, not a technical writer, and it really bothers me to know that all this could have been done much better if we only had the right talent to do this in house.

Realistically,  a startup company is not going to have the resources to do this right.  It seems that the technical writer as a role only materializes as a special function once a product really starts to take off, and the company itself starts to scale.  In the meanwhile, the user manual tends to be penned by a motley crew of developers, product managers or generally anyone with reasonable writing skills who has a few cycles to spare, with an observable impact on the quality of the documentation 😦

By my estimation, there will be at least 2-3 more iterations on the user manual before my current company will engage a technical writer.  Meanwhile, heartfelt apologies to all our end users for a document that may not tell you all that you need to know to use our product to its full potential.

How do you develop a product for end users in a different country, with a completely different culture and lifestyle, when you have a very small budget and a very limited understanding of the market?

Developing a product the right way that addresses end user needs is hard enough when the end users are clearly identified and collocated with the product team.   But if the end users are available at low cost, we can at least get 10-20 detailed interviews down in a relatively short period of time with very low cost.  That, plus a couple of strategically deployed ethnographical projects, can help a product manager slice and dice potential end users into archetypes, build up user profiles at an adequate level of detail, flesh out their needs, wants and expectations, and help drive the product concept.  We would be able to develop a product positioning statement before generating product requirements and specifications, which is the only way to develop good products in my book.

But when the end users are in a completely different country that do not share cultural norms with the product team, this can become a very expensive proposition very quickly. Not only does the product team need to understand the end users’ behavior surrounding their product space, they need to work overtime to understand the social context surrounding the rest of their end users’ everyday life.

It seems that the only way to achieve an adequate level of understanding of the end user is to team up with someone local who is versed in ethnography for marketing, spend a good two weeks in the target country, and put in some intense work surrounding detailed interviews, shadowing and immersion.  That can be an expensive proposition especially for a small company.   I’ve seen this done when I worked for a consulting company back in the nineties – it’s tons of fun, very educational and extremely intense.  But I really think this is the right way to do it.

The alternative way – developing a theory of what those end users need, without developing a deep understanding of the end users as people first, basically involves putting the fate of your next big thing in the hands of chance.  You MAY get lucky and guess correctly, or you may be so far off the mark that the product will never see the light of day.

My theory is that if a company cannot afford to do the research and planning, it is probably better for that company to phase its product roadmap and plan to expand into markets they understand first, build up revenue, and then invest in new product development for new geographies once they have the resources to do it right.

Phoenix update

The phoenix has gone down, definitively.  I gave it a 1 in 5000 chance to survive 4 weeks from February 26. It didn’t.

RIP and please don’t come back any time soon.  I have many more big fish to fry.