Skip to main content

Posts

Showing posts from 2014

The enterprise agile

Consumer Vs Enterprise Every time there is a consumer use product, we see that the enterprise comes up with a very customized version so that the enterprise does not have to adapt. This is with good reason. Enterprise is an entity that is too complex and having it to change would mean a disruption to the business  - something that the stakeholders are not very happy about. For example, take the iPhone and Blackberry. iPhone is a consumer centric product while Blackberry is a very enterprise centric product. However, iPhone introduced major disruptions to the way the enterprise security functions and forced enterprises to be more flexible with the way they allow employees to view email. This increased productivity since employees could view their emails at home or anywhere on the move and respond more quickly. Another example is Microsoft word Vs Google docs. The days when a simple document would have to go through multiple revisions with the whole track changes turned o

Nilgiris Acquisition by Future Group

One of the biggest things to happen in a long time in the Indian retail scene is Nilgiris acquisition by Future Group. Nilgiris is one of the few retailers in south India that has been very successful for a long time and also has been going through ownership changes for some time now. We do hope that Future group would provide good support for Nilgiris. Having had a chance to work with Nilgiris just once and understanding the dynamics of the Indian retail scene, there are several opportunities and challenges for all the parties involved - Future Group, Nilgiris and the Franchisees. Opportunities for Future group Working with a franchise network Nilgiris is one of the biggest Franchisee network and Future group can learn a lot from them. Better product mix management for various segments Nilgiri's strong point is that it has got the right product mix for every customer segment and the right kind of store for the location More complicated vendor management As

Sanitation Industry and Modi's Clean India Campaign

I am a socialist by education and a capitalist by profession. I am hence very confused by Prime Minister Narendra Modi’s plan for Clean India Campaign . The Campaign has all the similarities of a typical silicon valley startup dream campaign. Market gap Healthy ecosystem Consumer need Very large market segment with similar need All these should be driving plenty of companies to have taken advantage of this campaign and started making money. Delving deeper , I see some issues that could be learnings and also a few opportunities. #1 - Public-Private cooperation This is a very abused word right now in the Indian governance. It rarely helps the normal citizen. I am not sure how it helps the private players. It does help the bureaucrats shift the blame though. Public-Private cooperation will not work for India with such a small concentration of urban space and will lead to skewed demand and supply that will make the issue worse. What we should instead look at is h

Myntra and retailer's quest for profitability

How does a retailer scale and turn itself to profitability?? There have been several cases of online retailers that have struggled to balance scaling at the cost of profitability. The founders / promoters are at the cross roads on the need for more capital - that cedes control - to expand aggressively. They struggle with the need to attain profitability quickly. Their mentors are also not effective at advising them since there is no proper precedent for one approach over other. Looking at Myntra ’s case - a leading online retailer - It proves that it is never too late to get on the path of profitability irrespective of whether you want to grow aggressively ( Reference here ). All promoters would appreciate that. This case is strengthened by Zappos - an US online shoes retailers - as well that has been profitable right from day one. Myntra’s steps to attain profitability is well renowned and the slew of online retailers can gain a lot of insights from Myntra’s case. Pri

Counterfiet goods and the fledgeling e-commerce market places

India has a nascent and a very active market place. With good interest, the right climate for growth and right product mix, the indian retail marketplace seems to be going places. However, there are some alarming signals that seem to be ignored for growth that have a good chance of being dangerous to all the stakeholders involved. The issue I am talking about is the sale of counterfeit goods in all the indian market places. India has not had a history of strong Intellectual property rights. This time it is getting messier. The Indian marketplace model is very interesting and suits well to a country as diverse as India. The market place model floated by all the major e-railers suits the fact that the seller and the buyer can be connected for serving the needs for every day goods that are not necessarily covered by IP laws. India needs more effective IP laws since it is struggling with some products like traditional indian products that cannot be covered by IP versus modern produc

Being sensible with sensitivity

One of my first projects as a scrum master was to develop a product that would be used by teenage girls and mothers who are afraid of an unexpected pregnancy. I had to work with my clients on this project that was sensitive in nature on multiple grounds. Sensitivity #1: I was working with women on a topic related to measuring menstrual cycles and ovulation periods. It is not easy for people in India to hear a guy talk about menstrual cycles so openly. I had to balance between being sensible on how do we treat the entire topic as an objective discussion to shape the product while at the same time not seem like turning women into objects. It was a tight rope but we did it. Sensitivity #2: This was a realm that fell between medical and religious. The stand that the product took was not overtly endorsed by the medical fraternity in India. It was a new methodology that had data that was not collected by medical fraternity and hence concerns were there. This was a blessing

Tesco and Big Data

Tesco's missteps with its foray into United states of America and its accounting misadventures are unfortunate. Equally unofrtunate is the fact that the new CEO seems to focus on these negaitive events and fails to provide inspiration to the employees on the ground. Any large multi national corporattion would have to go through these challenges. However, it must be prepared to meet these challenges. It is very important for the leadership to handle this crisis without any impact to the operations of the organization. Employees need focus at a time of crisis so that they can keep the engine running. They do not need to know what went wrong in a part of the organization that they were not involved with. The leadership needs to provide the confidence that they can go past the crisis. The leadership also needs to bring the focus to the opportunities that lie ahead and abstract all the negativity around the crisis. In all this crisis, one interesting question that comes out is

Designing for Accessibility

The software world has starting being more inclusive. After serving only the geeks and the techies, a lot of the software that is produced in this world has started looking at how it can be mor euseful. One of the key constituencies of software usage is people with disability. The ADA (Americans with disability Act) has forced a lot of the software developers to look at this issue. The software world has also responded sensitively and with care making as much of the software usable by people with disability. One of the key components that we are looking at in this are people with visual impairment. Over a period of time, a lot of the software has made sure that the user experience is adjusted in such a way that is is intuitive. Google has been a front runner in this and a lot of others are also not left behind. Text The size and the font typology is very important. Choose those aspects with ADA in mind. Media like Images A lot of the media , including video and images ,

Analysis Vs Synthesis

The 2 skillsets that a product manager needs a lot are Analysis and Synthesis. I am a business analyst who turned into a product manager. It is easier for me to be reliant on my analysis skills since that is what I am trained as a business analyst. However, what is also equally important is the synthesis skills. How are they different Analysis refers to the ability to break down a problem into constituents and start attacking them. This helps the product manager a lot when there is enough feedback from users and all the product manager has to do is just carry it out. There is no need for prioritisation from the side of the product manager since the user’s preference would clearly give that information as well. This works well when the product is an already released product and it is not difficult to understand what is needed and why it is needed. Synthesis, on the other hand, refers to the ability to piece together multiple pieces of information to understand t

How to pitch your product

Product managers have to be on the road with the sales team and try to understand the market better. Any amount of market research is not sufficient to help understand what should the product shape up like. In case you have observed, We need two kinds of pitches to make - they need to be made on a specific scenario - some times to the same contact at the different times. Scenario 1:  You want the prospect to start listening to you. The prospect has not yet connected with you. This scenario is the most common when we do cold calling or when we meet people in conferences / fairs. The prospect has no idea who you are or what problem you are trying to solve. In this case, you need to have the following information What is his/her dominant problem? What figures do we have to state it more quantitatively? To put it in better perspective, The dominant problem of a typical retailer that we meet is as follows: I am not sure what kind of stock is left with me at the end o

Communication in cross-functional teams

Working in cross functional teams is the occupational hazard for product managers. A typical product manager needs to work with 3 kinds of teams: Engineering team - comprising of developers, testers and IT operations Sales / Marketing team Management team The product manager needs to have different set of information - or rather information represented and expressed in different ways for the three different teams. Engineering Team Focus: Focus on what needs to be done. Define clear milestones  Clearly communicate focus of the product and end user gain Help take decisions to architect the product Detail the product road-map from the engineering side Sales/Marketing Team Focus: Focus on what the product positioning needs to be Map the competitive landscape and find out how we are different from our competitors Clearly communicate the overall marketing / sales goals - with respect to details like channels, goal for the period Detail out the communication plan wi

Maintaining multiple versions of a product

A product team , when it has more than one client, faces a challenge when it has to maintain multiple versions of the product. Typically the implementation team would have made some customizations for every installation for the product. However, when they release a new update, they struggle to make it work for all the products since there are customizations and the new update might not be compatible. There are several considerations that a product manager needs to take while deciding on the product strategy. Saas versus Installation Having a saas product makes it easier for the engineering team to push updates. If it is a installer distribution, There are the team will face challenges with distribution. Compatibility is also an issue. The biggest issue however, from the user perspective, is data migration from the previous version to current version. The best way out of this is to make it a service as well. You can decide whether you want the customer to pay for tha

When to pivot

Pivoting is a very painful decision for Product Managers. It is also a decision that we , as product managers, dread. Pivoting in essence is one of the key decision points that a product manager needs to always be on the look-out for. A little bit of Context The job of the product manager, at various levels, is also to look at it from a 30,000 feet level, understand the context the product is perceived by the customer and understand how he can make the product better for the customer. This is easily said that done. Product managers tend to get lost in the daily details of running the show that their interactions are always on the transactional level. Irrespective of whether the product is doing well or not, a product manager needs to watch out for the changing landscape. To Pivot ot Persevere The product manager needs to make a hypothesis on whether there needs to be a revision on what problem it is solving. The hypothesis needs to provide a result that will hel

Minimum Viable Product

When we create a new product, Product managers always grapple with the problem of when to take the product for customer validation. Taking it too soon would be the prospects are not interested in what is being demonstrated. Taking it too late means that we could be grossly wrong and any feedback that comes could not be that valuable. Another problem is taking it to all the prospects might lead to unsatisfactory  comments on how the product is still not complete. How do we manage thing timing issue? A simple concept of minimum viable product could help us understand when is the right time to start the demonstrations. Minimum viable product is the core product that satisfies the needs of a chosen subset of the target audience. It has just enough for us to focus on a subset of prospects, validate understanding and move on. What it is not MVP is often misunderstood as a the bare minimum of a product that can be developed. This understanding is incorrect. The empha

The right business model for your product

How would you decide what is the best business model for your product? Deciding on the right business model is very important for the product. It does not necessarily mean what is the price of your product. There could be no price for your product - though that is a myth. For example, we think google or Facebook is free. However, we are never the customers for Google or Facebook. It is the advertisers that are its customers. What we need to figure out when we decide on a business model are as follows: Who is my target audience? Who is my customer What is the price. How is the support model going to work Who are my partners While we do not absolutely need to price a product, we need to understand how we would make money. For example Open ERP does not price its product. However, its product is not the ERP software but really the hosting, service and training that it offers. While pricing is an important part, what is more important is in realising who is you

Cataloging problems

How do you do your job as a product manager every day if you do not know what problems you have set your product to solve? One of the most important tasks of a product manager it to catalog problems that prospects / target user base faces. Just follow the steps and you can get really good at it. Step 1: Listen to potential users When you go out to meet people - either potential users or potential customers - you need to listen to what they speak. If you are really good, write it down as soon as possible as you keep listening. That is just step 1. Step 2: Look at what they do As they keep talking, chip in once in a while and ask them what they do and why they do what they do. While this might seem an innocuous question, it is the most powerful question and has enormous power. Reason: You are going to get actions from the customer. Step 3: Listen carefully to the one key thing that they say they are actually looking for. When customers actually demonstrate to yo

Defining your product's business value

What is in it for your customer and user to buy and use your product? While we all would have answers for this question, we need to understand what the users think of our product. When we started our product, this is what we came up with: We were all excited and would roll our tongues and try to convince our prospects that this is the business value that it was providing. Turns out we were wrong. While we are providing these value adding aspects in our product, these are not the real “ BUSINESS " values. Notice that the word business is in bold. What they really wanted was a simple web page that tells them how their business is doing without jumping through hoola hoops. The biggest business value for saving time on doing mundane calculations. They did not want to manually consolidate sales of 3 stores every month or every time they needed to take a decision. Once you have captured the business value, how would you track how you are doing on that business val

Inbound Vs Outbound leads

Getting leads for a new product is very critical. It helps keep the momentum and helps us get initial feedback. When we design a new product and have a functional prototype ready, we typically do one round of testing and demonstration within our organisation and collect feedback. What matters more is the feedback from our prospects - potential users. When we have a functional prototype ready, we have 2 paths to choose from: Start a web-site , have some information and quickly get leads from the page Go out on the field and interact with potential users and prospects, demonstrate the application While we see a lot of product teams and startups doing the first one, It is the second path that matters till the product goes to beta. Taking a product to beta is a big task. Taking our example, we took 2 prototypes and 8 months to even start alpha and our beta is in 18 months with 2 customers. While all teams are tempted to have inbound leads, the problems there are In-b

Constructing the Product Roadmap

When I started out in the team, I was tasked out with coming out with a plan so that we can demonstrate the product with real data. The idea was to demonstrate it to our prospect with their own data and win them over. However, when I started working, I found out that what we lacked was not a plan but a vision. I quickly put together a one day workshop with our team and our product owner. When we started talking, we talked about several things and figured out that we needed a plan of various proportions. We needed a plan that could help us one the following: Provide a focus for the long term with near term focus on just one thing Help us talk to prospects on what we are going to do Help us decide on when we would need to focus shift on which function - Engineering , sales etc We also did a quick “Product in a box” exercise so that all of us in a team can practice and imbibe the elevator pitch. We needed this since we had to do this pitch at several levels - Inter

How to name it !!!

It may seem insignificant but forms a very important part of both the product placement as well as marketing for the product. We have been hunting for names for more than a month now and just have a working title for the product. The problem with the working title is It is way too long it is not easy to remember It does not contain the essence of the product We have the following criteria for a product name Easy to spell and remember Relevant to the product space Should have been used by any other relevant software product While we have enough suggestions that cross the first 2 criteria, we hit the block on the third one.

Finding your target audience

The biggest task of the product manager is to find your target audience. Typically it is a very tight rope walk. You define it too narrowly and you would struggle to generalize the product later. You define it too broad and you would struggle to satisfy a lot of people and the product might not take off at all. There is this awesome post by Dave Mcclure on why Niche target segment works. Blog link here . What he says is mostly right and that is what we did as well. We did it mostly by accident. We had to define our niche because we could only talk to those kind of retailers and get data from them to start developing the data. It did have its upside. We were very clear on what we wanted to develop and we are slowly talking to retailers and adding more scenarios. As we are doing this, we are also talking to a slightly different set of retailers. This helps us incrementally build our product while also generalizing the existing features. In our case, we did not fin

Prototype Vs Product

What is the difference between a prototype and a product? I will try to summarise this based on our experiences and understanding. When we started building out this product, we did not have access to real data or to real customers. So we did the next next thing. We stubbed out the data. We presented the application on NRF, Big Show and received feedback from prospective users. Prototype#1: No real data and no real customers. Just functionality We received a real data set form a prospect and started out to develop based on the data set. What we missed out were the real-time scenarios based on the data. We showcased the prototype and received the next set of feedback. Prototype#2: Real data but not real-time scenarios. Functionality with limited scenarios. Once we understood the business of the customers and what they do, what they want, we continued building the prototype and now have a product with 2 customers. Product: A base-lined prototype that handles a

From a Business Analyst to a Product Manager

Being a business analyst is probably the easiest part of the product manager. I did not start out as a product manager and the role evolved naturally. When I started my role in the product team, the following questions kept coming back. Why are we doing this product? Is there enough need out there and do we know what returns we would get? Do we know who we are building for and what are we building? While these are innocuous questions that can be posed to a business analyst working on any IT project, what differed was there were no one person or team we could pose these questions to to arrive at answers. We could also not design workshops in case there were multiple stakeholders to arrive at these answers. I ended up doing the following and slowly what I started doing defined the role that I had taken up. I started doing market research to understand what are the market segments available for my product Visiting retailers and trying to understand their pain points h

The accidental profession: Product Manager

I work as a Lead consultant at Thoughtworks and my role is usually called Business Analyst. This post is entirely about hoe I ended up becoming a Product Manager. Like what Steven Haines tells in this book: “THE PRODUCT MANAGER’S DESK REFERENCE”, Product Manager is an accidental profession. "You may have backed into Product Management from another field or business discipline.” I landed this position because of the following reasons: We are a services company. No one was interested in a product team. No one was sure what to do as a Business Analyst in the product team No one was convinced that this specific product would be successful. I ended up getting the job and was left to figure out what to do in the team. I was to be the business analyst trying to line up functional work for the product engineering team I have to manage the team - with respect to the team members and make sure I plan for the functional work to complete I was to interact with our current