Showing posts with label misc. Show all posts
Showing posts with label misc. Show all posts

And I am back to my blog. Not that I had disowned Agilecat, but just that I have a little more time these days compared to the last three years, as I gear up to transition into a new product at a new organization.
This comeback blog is dedicated to all product managers who have renovated themselves to become ‘product owners’. I realize that there has been a lot of deliberation and analysis on this topic, but in today’s post, I am going to touch upon just that one aspect which is crucial to both the roles - ‘physical presence’.

Yes, you got to be there. At the right time with the right people! A nice PM stays in constant contact with his ‘customers’, and to be a nice PO, he must and always be present with the scrum team. This is one large aspect of variation between the descriptions of duties between these two titles.
The Product Manager, by definition, is the voice of market. He is coached to stay out, experience the souk, observe the users, study the customers and so on. The agile Product Owner role characterization lays a lot of emphasis on conducting planning meetings, giving first hand feedback to scrum teams, participating in review sessions and so on. So from a distance, this looks pretty clear – PM stays out of the office, while PO sits alongside the team. Two roles, pretty distinct, right?

If you look closely, these roles may appear to have dissimilar portrayals, but share a common goal - that of connecting the dots between the market and the team. Yes, it is fundamental for a good PO to understand his customers and market, and equally imperative for the PM to identify with his team dynamics. If there is one person playing both these roles, he’s got to master that sweet balance of staying home with the team, and also out their in the field!
Time management and self prioritization become crucial for such an agile PM/PO person. His typical calendar week best describes the role he plays, and nothing else.
Agile methods encourage frequent release iterations, and call for stake holders, sponsors etc. to be significantly involved in product development. This helps in reducing risks, and at the same time makes it easy for the PM/PO to engage users and sponsors by making sure that his product stays in touch with them, while he stays in touch with the product.
Exploiting social media tools to engage, listen and gauge the market sentiments is not new anymore, and is more and more becoming mainstream in product management techniques. While it clearly does not obviate that need for physical presence, it surely helps the PM/PO to better prioritize his ‘facetime’.

Some argue that being a product manager and an agile PO at the same time results in overburdening of one person, and that is true, mostly because with that oath of “product owning” comes a never ending endeavor to help build great agile teams, along with winning products. Another way to look at this is to treat the agile team as another ‘product’ in the making, and PO playing chief architect on that project.

May 10, 2008

Loving your product

Believe me, killing your own product is the most painful task you can ever be "told" to do. Sometimes, we are in so much love with what we build, that we tend to forget the ecosystem around it. This could be a BLUNDER for any product manager.

First line of a PM's job description surely reads - "Define the right product to build". And when this definition is changed in such a drastic way that closing current development makes more sense, more often than not, teams start to get frustrated and fidgety. What others may not understand (and the PM must) is that "being in business" is more important and critical than being on the cutting edge of technology or building beautiful products.

For a team, to collectively enter the comfortable "I-know-enough" zone is pretty common. I have seen some products getting closed / realigned so late and with such convincing reasons that at times I start to wonder why not earlier! Things could get tricky when there is a trade-off between making early decisions and minimizing risks. How to handle this is not just a strategic stunt but also a challenge for PMs.

So what could be the reasons that could lead to shelving of products?
1. Technological imbalance:
Could be caused by inventions, acquisitions, and even by slow development progress.

2. Organization wide priority shuffle.
Tying your product with the mainstream value chain of your business is crucial. And with every
adjustment in this chain, products' priorities are often realigned.

3. Turbulence in the ecosystem
What do you do when you find out that your potential customers will not be in business by the time you are ready to ship? Stop. Think.
What do you do when you find out that your competitors are marching at a velocity that is several times yours? Think. Stop.

and last but not the least
4. Dearth of dollars!
Sponsor(s) could lose the confidence or money and may pull out.

Do you know of more reasons?
And yes, my big question is still open - should you "love" your product?

April 15, 2008

Doing Breadth-First

The_Big_Picture_2If you are starting on some new project, and your role needs you to define and prioritize requirements for a product, taking the "Breadth-First Approach" makes a lot of sense.

Getting to know the overall scope of your system should be the first target. Formulating accurate scope could get tricky at times. However, the first few questions that you should ask (to anyone else who knows even a bit more) must include:

1. Who are we doing this for? Look for proper nouns.
2. Which two main problems will our system solve?
3. Who is paying for this?
4. What is the release schedule?
5. What are the risks (as of now) and external dependencies?
6. Is someone else also doing similar work? (inside or outside your organization)

If the project is already underway, you may want to look at some inception stage sketches. If the project however is relatively young, you should draw those yourself. At some point, this effort must incorporate some kind of a conceptual domain model.
The next thing that you must think about is how would agile methodology scale to adjust with your team and the size of your product. And no one at any stage shall forget that along with the promise of delivering value pretty early, agile processes are also designed for the team to learn how to deliver value more effectively and efficiently.

Lastly, if you are much involved in capturing requirements or selling the product, you should always start to prepare (and even rehearse) your elevator pitch. You must have crystal clear, and unambiguous answers for: who you are, what you do, and why you do it better.

And finally today, I leave you with a quote that quite well summarizes the entire agile philosophy:
It’s never the size of the step that a person takes that counts, but its direction.
--Narrative Means to Therapeutic Ends, Michael White & David Epston