Thoughts on Product Management
A big “Write That Down” welcome (whatever that is) to a new linker / blogroller — Thoughts on Product Management. I’m looking forward to diving in and reading the archives, and look forward to all future thoughts / ideas / comments / etc…
Push It Forward Revisited
When in a small company it is SO easy to get tied up and fall into “traps”. These may include things like running long release cycles, creating too much documentation, etc…
When many people are wearing numerous hats around the company, it’s easy to lose priority on where you need to spend your time. The key for me relies on a couple of things:
- Are we listening to our market?
- Are we driving our products where the market tells us?
- Are we making sure to continue to innovate in addition to acting on market data?
- Are we pushing the product forward?
The innovation point is key, because (in a start-up especially) you don’t want products to grow stagnant unless you want them to grow stagnant. The market is nascent, a lot of revs will be driven internally unless the early adopters turn into early majorities and so on.
It’s a tricky balance between managing a development schedule, internal / external roadmaps, and making sure everyone is properly versed on what your products do. My philisophy is, everyone in a small company has to wear their Product Manager hat at some point or another.
If you look at the “typical” product manager job description, there is simply way too much on there in order for a single person to be great at the entire job. The thing at a small company is, a PM shouldn’t be expected to actually do all of the things tranditional brand / product manager would do. Understand them yes — but do them…not really possible.
Since everyone is so involved in all products day-to-day, it’s easy to get folks on the PM bandwagon. The difficulty for management is a) making sure people understand product management and b) making sure people don’t start stepping on toes and going overboard.
There are some rules I live by having been in two software start-ups now: what the founder says goes, and what management says goes. They are simply not looking to PM’s to make sure a specific product has a good P&L. That’s the responsibility of the business, not a single PM.
I’m putting some thoughts together on what the typical software start-up PM role looks like. I’m feeling the blog vibe a little bit more lately, and my wheels are starting to turn…
Happy Friday, everyone!
Delivering Clarity
I’ve never worked with non-software products. This could be perceived as either a curse or a blessing, I suppose. I don’t know what a Product Manager for a non-software product would go through to ensure everyone in his or her company “got it”. However, one thing I do know, it’s tough to drive clarity in software companies.
It’s invetiable that people just won’t get it. It’s not their fault, by any stretch of the imagination. But, as a PM, I see it as a responsibility to get everyone on the same page. Having just stepped-in to a company that has multiple lines with multiple technology-based products, this has been an overwhelming task.
There are plenty of things I thought would work at the outset, but I’m molding to shape what’s best for the company as I go. Since all of the products I’m working with combine into a “ecosystem” of sorts, it makes it tough - the natural thing to do is try to cover everything at once — all for one and one for all sorta deal. This doesn’t work — at least, not in the scenario I’m dealing with.
The approach I’ve decided to take is, break these out, simplify where possible, and make sure everyone gets it. I’ve been working this strategy for around 2 months, and it’s going well. There’s some places where I can’t enforce this and need the help of my boss and others, but that’s OK. The thinking I’m trying to change has been going on for over a year. I’ve never thought it’s impossible to clear things up — maybe difficult, but if it wasn’t it wouldn’t be a challenge.
So, what’s my overarching theme? Keep it simple stupid (K.I.S.S.). Simply the lines / suites, and productize each product as a product - not as an “ecosystem”. Not everyone can keep a picture of an entire system in their heads, but they can understand “this is product A, and it has features B and benefits C — here is a 50,000 foot workflow”. Then you can start getting into how each product works together.
One thing I’m picking up on does relate back to people having a set image in their head of things for over a year. I’m noticing that, even though it’s easy to see how easy the products are once you get it and it’s explained in the right way(s), there’s slippage back into the old ways of thinking.
I guess that’s natural. It just takes time and consistency of message. Making sure your productizing to the right standards and then take that message and push, it should be fine. Yes, I’m dealing with this for the first time, and learning some GREAT lessons along the way. But I don’t know if it would change from one company to the next. You learn to recognize when you’ve tried to deliver clarity in one way and people react another, but outside of that, it’s sorta just trying to find the right way to talk about products to the specific company.
Maybe I’m relying too much on the start aligning but that’s just what I’m seeing thus far. Hopefully I don’t sound too much like a crazy-person.
Solutions for API’s
As there are more and more new-fandangled Web-based products released on to the market, one of the things I’ve noticed (yah, me and probably everyone else on the planet), is that they feature the ability for other developers to write their own applications on top of them.
This is typically accomplished using an API. In today’s world, more often than not, it’s a URL-based API. A developer says, “get me this content, based on these parameters” and the service provides an according response in either text or XML or whatever format.
I came across a new company today called Post App. The premise is quite smart (based on what you can tell from a terribly simple home page, and an e-mail sign-up form), in that it’s catering to the set that may want to write their own applications, but don’t necessarily have the know-how to do so.
This is important for a couple of reasons, that I see.
- Developers who write the API’s are probably smarter than most of the developers charged with building solutions on top of those API’s
- Business stakeholder’s are looking for solutions that get built quick (whan don’t they want this), and work really damn well
- Users that are aware of this “Web 2.0″ thing are always on to trying to find that next cool service — that next 30 boxes, or that next Flickr.
I’ve signed-up for their private beta, so I’m hoping that I get invited in. I’d love to see what this is all about, because I’m really into the idea of making the creation of customized Web services on top of existing API’s much easier for a larger set of folks. There are tons of ideas floating around out there that are useful.
The tricky part that Post App faces is opening the service up to a level that’s comparable to actually writing the stuff from scratch. Yes, this seems easy in principle. However, as a hack PHP developer who has entertained and researched the idea of using freeware apps / code that already exist to “try” and get something done “faster”, I know that it’s more often than not, a better choice to write your own application from the ground up.
So, that being said, I’m interested to check it out, as see what the reaction is from developers.
