Life of a Business Principal in Consulting

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...

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 e...

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...

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...

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 ...