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.
All this while, doing market research, if you have been hunting answers for the "what-the-customer-wants" question, I can give you the answer. Here it comes. The envelope please...Your customer wants a superior product that delivers unique benefits and excellent value.Simple, huh? Let’s look at the word value.Value is a function of the benefits, features, and quality that are built into a product versus the price of the product. The more benefits, features, and quality a product can deliver at a low (or reasonable) price, the more value the product has.“… the more value a product has” Actually, that perfectly-reasonable sounding phrase is misleading. A product does not so much have value as the consumer perceives value in that product. It would be quite convenient if you could simply pour value into a product as you pour a few litres of oil into your car. But value is not an absolute quantity. It is relative. It is a perception.The fact is, no one knows value. Only the customer knows it. (At least he knows it sometimes and about some things. It is actually more a perception, a feeling, a sense.)A nice-PM understands that during market research, it is his job to find out what the customer defines as value in a particular product or a class of product. Some questions that our nice-PM needs to ask that relate most directly to his products value would be:1. What do you look for in product X?2. What criteria go into making your investment decision?3. How important is performance and robustness to you?4. How much are you willing to pay for high performance and robustness?5. What tradeoffs are you willing to make to save money? What features or levels of performance are you willing to live with to save money?
Most of a Product Manager's business life is spent in avoiding problems. However, in market research he has to eagerly seek out problems. Problems are very strong motivators of consumer purchases, and customer buy-in's. People will buy something they believe will solve a problem that afflicts them.Problem detection studies are often quantitative surveys designed to define problems in a category and then rank them based on intensity (How bothersome is the problem), frequency (How of the does the problem occur), duration (How long does the problem last), and preemptibility (What is the extent to which currently available products can solve this problem).To discover needs and ferret out problems, a nice PM conducts surveys and asks questions. He may also arrange to actually watch a process, whether that process is machining a precision part, mowing the lawn, opening a bank account, or designing a mobile application. By studying the process, he identifies gaps, needs and more importantly, problems!There is a catch here, instead of looking for ways to arrange work processes so that they are more efficient, our nice PM is looking for ideas about new products that will appeal to consumers by making tasks or processes easier, more efficient, more pleasant, more profitable and so on.Talking of task and process observations, they should be combined with questions:1. Ask the potential customer to list all the tasks or steps involved in this project.2. Ask him to rate the steps from pleasant to unpleasant.3. Ask why he finds a given step pleasant or unpleasant.4. Ask if, why and how he would would like the step, task, or process changed.We have to however remember that market research is a technique to be 'used' and not to 'rely' upon. The bad PM (like David Ogilvy remarked in Confessions of An Advertising Man) starts to use market research like a drunkard uses the lamppost, for support rather than for illumination.
Some product managers are control freak, and some are too cautious. Those are bad fishes in my opinion. Teams that work in agile style, developing new products must be working close with the customer. There could be instances where a team is newly formed and folks do not have much know-how about the attitude, way of life etc. of customers. The bad fish PM if given this situation does the following: 1. Runs short sprints, like 1 week. And here is the bad part - he claims that since he doesn't have trust in the team, he can't afford to lose control. 2. Although the team has good and proven experience in software engineering (although not in the current domain), they are NOT allowed to talk to customers. 3. All requests from customers come via the PM. (ok, this could be fair). If developers have doubts or questions, they have to ask the PM, and he decides when and how to take those queries to customers. 4. He yells in some meetings "I know the customer, I know what he wants! Do what I say." 5. No single soul in the development team, yes no one, knows who is the customer. Forget about what customers do and where they are! 6. PM arranges a face to face workshop with customers and does not take any developers/testers along. Do you think this team (which is composed of experienced guys who could be new to the system) can ever grow, emerge and delight the customer?
Speed is increasingly of the essence in new product development. The idea is to get to market fast. But how do you "do it right" and "do it fast"? Well, just because you might do something slowly doesn't mean you'll do it right, and it's also true that speedy execution does not preclude high quality of execution. No two ways about it, though, it does make the task more challenging.The single most effective way to speed up the process is not to make mistakes. Instead of cutting corners, build in quality at every step, so that you "do it right the first time" and don't have to waste time doing it over again.Product managers should invest a lot of time in defining the new product at the outset, so that everyone doesn't squander time on unfocused and unnecessary activities.Let's not run a relay race. Ever since Henry Ford made the assembly line practical, businesses have been obsessed with sequential processing: do this, finish it, then do this, finish it, then go on to this and so on. To whatever degree possible, you should try to abandon sequential processing for parallel processing. Divide the task at hand to several parallel steps. And of-course make sure you maintain constant intercommunication.Through clear definition of corporate goals and strategic plan, you should prioritize the proposed new activities. Which ones are important to work on now? Which can be back-burnered? Which can be scrapped? If need be, make hard choices, and then, get set to work on them.Speed is important in product development, but carelessness is unforgivable. It is not unforgivable just for some highflauntin moral reason, but because customers will not forgive products that are flawed in design or in quality. Most people spend much of their lives trying not to look like fools. Your customers are no different. They won't take a chance on a new product that has a flawed reputation.
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 everyadjustment in this chain, products' priorities are often realigned.3. Turbulence in the ecosystemWhat 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 least4. 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?
If 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
If you have to show-off a new cool feature to customers without having them to download or install stuff, do a screencast.If you need to popularize a new tool that you are using and find useful, do a screencast.If you just prepared a new mock-up and wish to communicate it and it's purpose to your team, without collecting all of them in a room, do a screencast.If you have a new slide-set that you'd want the readers to 'understand' and not just 'read', do a screencast.If you wish to teach others on how to install, configure and use your product, without asking them to read through the lengthy manual, do a screencast.In any successful project, intra-team communication is of utmost importance. And when you have globally distributed teams with time differences, it is more suitable at times to do a screencast and convey your point rather than wait for mutual free slots and discuss over telecon.Often, putting across tutorials or new ideas in video attracts more and wider attention. And yes, voice narration is a certain cure for ambiguity.One of the best tools in the market for producing screencasts is Camtasia Studio. A complete list of tools is here.And here are some examples of good screencasting.
I attended the "Certified Scrum Product Owner" course at Helsinki last month. Kenny Rubin was the trainer. He gave some very useful insights to the group about what exactly is the role of a PO in an agile project. There were some lively and interesting discussions going on the room for those two days.Here are a few key points that I felt worth noting in my notebook during that course:* Good product owners generally hate "work in progress".* Real and active product owners 'must' see and approve the sprint content / demo before sprint review.* User stories are not contracts.* 'Definition of done' for user stories may get modified as result of interim demos.* Product owner is not a tester. He should be presented only functionally tested stuff. He then may do user acceptance testing.* Product owner's boss can not change the priorities in the product backlog! He may add requirements though.* If a product owner plans for extensive documentation, he must also keep in mind that he is responsible to maintain it.Last but not certainly the least:* A good product owner should always "be there" for his team.Finally, I leave you with the opening lines of Kenny while he was giving us the traditional introduction about "Why Agile?""...Let's assume we are a team, assembled here on day-one to kick off a brand new, huge project. In future will there be any other day when we'll know any lesser about this project than what we know today? Now, when do you think we should make all the crucial decisions?..."