By Invitation Only

Tom Glocer, CEO of Thomson Reuters, writes this about inherent human insecurities around exclusivity that marketers exploit in creating maximizing seller’s surplus

Although the victims of this enormous fraud (Subrata: Tom is referring to Bernie Madoff) deserve our help and sympathy, at its core what made Bernie’s scam so powerful was the seductive offer it extended to investors to let them into the inner circle, a private club or sanctum sanctorum to which few are ever admitted.  This reminds me in an odd way of the allure of the luxury goods market: “Madam, we could not possibly sell you a fabled Birkin bag; the waiting list is years long.”  Followed, some weeks or months later by the helpful call of a sympathetic store manager who reports that one such extremely expensive handbag happens to have surfaced at a sister store which might be available if the shopper could act fast.

I recently was invited to join PeerPOwer – a professional networking site. The site promised exclusivity – one can join “By Invitation Only”. Until I read the home page


Question: Why does the industry spawn off regional flavors of online networking sites (PeerPower is a Times of India initiative)? I mean, wasn’t LinkedIn quite adequate? I can understand this for matrimonial sites like this and this where physical interaction is a neccessary step two, but this one beats me. Any thoughts?

Product Management in a Start-up

expertszon by Gopal Shenoy

Is a product manager needed during early stages of a startup? If yes, what should be his/her role,  given that everyone tends to wear multiple hats and the distinction between Product Management/Marketing and Architecture/Development is blurred. Is this a healthy cross-pollination or a disaster in the making? (I had asked this of Gopal, triggering this post: Subrata)

I will offer my opinions on these questions drawing on my experience in the software industry and having played a role in the creation of successful products and utter failures.

1) Is a product manager needed during early stages of a startup?

Yes, a product manager is absolutely needed right from the early stages of a startup. A bunch of engineers can band together and write awesome software. But often, engineers fail to ask the fundamental questions:

1.    What problem does it solve?

2.    How many customers have the said problem?

3.    Are the customers willing to pay to solve the problem?

4.    Who is going to buy the darn thing and will they pay enough for us to be profitable?

5.    Does this solve the problem the way the customers expect it to work or do they have to change their ways?

It is a product manager that will help a company to answer the above questions and make sure product development is aligned with customer problems. Only then will a company be able to create a business, sustain it and be successful.

Otherwise, you run into the infamous argument (I call it a trap) that I have heard over and over -if we build something, they will come. No – unless you have something they absolutely want at the price they want, they will NOT come. If the user experience does not save them time or money, they will keep solving the problem the old way because a) they do not have time to learn new ways and b) humans by nature are resistant to change.

There have been very successful products that created paradigm shifts, but more so because of the tremendous value and differentiation they offered the customers. For example, in mid 80’s, Pro/ENGINEER the 3D mechanical design software from PTC was the pioneer in creating this market segment by switching a lot of users from AutoCAD 2D design software to 3D. It was hard to use, it was expensive, it needed designers to completely switch their ways, but the design benefits were very obvious to those users that switched (and not to mention PTC’s very aggressive marketing and sales force). But paradigm shifts are rare. I am not suggesting that you do not innovate and create new ways to solve existing problems, but new ways should always have easily understood customer benefits. Otherwise, you will face adoption resistance.

You could also argue that one could launch a product and let the customer community take the role of helping you discover problems the product could solve. Yes and No. I would argue that it needs to solve one particular customer problem well enough to get noticed even by the early adopters. Unless you do this, no one is going to even consider buying/using your product. Unless this happens, no one is going to help you shape the future of the product to solve other problems it could potentially solve. I will draw an analogy – does anyone ever get out of the house and start driving hoping that you will end up somewhere nice by chance. Not very likely. But we are willing to take such a risk developing products, hoping that we will strike rich?

In this day and age of the internet and its free products, there are companies that have created free products that have sustained themselves for very long (Facebook and Twitter come to mind), but in the long run even these companies have to figure out ways to monetize their business to survive (and by the way, the world is still watching as to how Facebook and Twitter are going to do just this.)

2) What should be a product manager’s role in a startup given that everyone wears multiple hats and the distinction between Product Management/Marketing and Architecture/Development is blurred?

The roles of Product Management/Marketing are blurred primarily because the industry does not have consistent job descriptions for these roles. In some companies, Product Marketing does market sizing, segmentation, positioning and pricing decisions and Product Management figures out the customer problems in the selected segment and then works with engineering to make sure the right and usable product is being built. In other companies, all of this ends up with the Product Manager and this is usually true during the early days of a startup.

But are there limits to what the product manager needs to do, such that he/she is not spread too thin? Yes, there are. I tend to use a very simple litmus test to determine activities in which a product manager must be involved – Does this activity help the product manager in listening to the market and making sure that the right and usable product is being built? If the answer is No, free up your time by getting it off your schedule.

I would especially shy away from getting involved in architectural and development related decisions for a very good reason. As a product manager, it is your role to think like a customer and then inform engineering what problems need to be solved and how. You can advise engineering in terms of customer expectations in terms of scalability and performance. But it should be engineering’s sole responsibility to figure out how to architect/design the product to solve the problems a product manager has identified. If you get involved in the latter, very quickly you are going to look at problems in terms of implementation details rather than from a customer’s perspective. Not a good idea.

Having said this, I will not hire a product manager if he/she is not ready to wear multiple (but relevant) hats even in a mature organization, leave alone a startup. Product manager’s role is one of the most cross-functional roles in an organization. Hence, by definition, such a role requires one to wear multiple hats, supporting sales, supporting marketing efforts, making sure the right product is being built by engineers and so on.

Thoughts? Comments? What have you learnt from your experience as to what works and what does not?

gopalshenoy7Gopal Shenoy is a Senior Product Manager at OnForce, an online marketplace for IT/Consumer Electronics services, based in Lexington, MA. He has 15 years of experience in product management of software products primarily for small businesses having worked at companies such as SolidWorks, RSA Security and He is an avid blogger on product management related topics on his personal blog at

Picture credit: Author

Yours visually

Wireframing a product or enhancements is a great way of validating customer propositions. Given the choice, customers and prospects will any day choose an html prototype over powerpoint hyperbole. Thus it is sad that html prototyping remains suboptimally utilized in the product development cycle – overused at the begining and consigned to the trash bin before it has yielded all it could.

I am no genius figuring out why a touch-and-feel prototype is more effective than paperware. The commercial/sales guys figured it out much earlier. The zeal to sell (or to just awe the audience) leads down the slippery slope of over-jazzed visual prototypes getting in front of customers. Overpromise. When the rubber hits the asphalt things start falling away. Engineering cannot deliver to the wireframe in the committed time or without overhauling the architecture. Underdeliver. A tool to elicit, refine and enhance requirements has been relegated to a cheap selling trick.

Html wireframes are much derided within the engineering fraternity as mickey-mouse. The prototype quickly dies off and after a while no one even as much remembers where the code is. What a waste. With some thought, practice and process, it is possible to extend the wireframe into the development stage as a bona fide artifact. Preserving the spirit, content and visual signature of a wireframe right throughout the development cycle is more guaranteed with this extension. Product Managers and Usability folks should retain some oversight into the engineering process to ensure minimum deviation from original state.

On the side try this. Ask Usability or engineering to give you a flash version of the wireframe. Put that on the thumbdrives of every salesperson in your organization. Trust me, leaving a “live” version of the product with a prospect is times better than leaving dead-tree version collaterals. The sales folks will love you. The flash and html versions will come in very handy when you are running subsequent marketing campaigns and want your prospects to see and play with the product over the web before they sign up for a trial.

Wireframes are not use and throw. Rather used as flow and grow they can return a staggering return on investment for the product in question.

Update: Seth Godin has a brilliant post on measuring ROI on design. No, he doesn’t give you the spreadsheet you are looking for. On the other hand, he leaves you with enough food for your gray cells. Quintessentially Seth.

Dislodging home-grown systems with Products

It is not unusual for a Product Manager to find that his product is often not up against a competitor product but against systems and tools handcrafted by the potential customer. Underestimate the replacement inertia at your own peril. The home grown system has entrenched through emotional bonds with the same users who you are trying to wean away. Never an easy task.

Key to establishing the value proposition of your product is to focus on the future – not on the present. One big advantage a product company has is its existing and potential installed/user base. Imagine an in-house built editorial publishing system that is used by 100 journalists against a product-based offering that is used by 2000 journalist across a diverse user base. The use case exposure of the in-house system is bound to be limited, reflecting in its ability to evolve quickly and in line with market trends. In other ways, even if your user base didn’t grow – you have 2000 minds feeding you requirements versus the 100 that your prospect has. Drive this point home.

Product Managers, Marketers, Engineers in the product firm wake up each morning (or should wake up each morning) with just one thought – how to better the product. That’s how their DNA’s are programmed. To do this they network, talk with customers, engage with the industry, partner with firms and keep abreast of the latest technology and all that. The customer on the contrary wakes up each morning with very different things that bring them to work. Just as you don’t want to wake up with their priorities, they shouldn’t be burdened to wake up with yours. Trust the experts – tell your potential customer this.

If you are selling into a large organization, it is not unlikely that you will discover (after some investigation, a couple of beers and a Deepthroat) that your potential client has a proliferation of tools, each solving the same problem with different resources, different approach and different technologies – all scattered across different parts of the same organization. Use this information to create compeling Return on Investment (ROI) arguments. Position yourself as the messiah who will bring about uniform technology to solve common (or almost adjacent) business problems.

Sometimes trying to dislodge a home-grown system is more onerous than fighting a competitor. First, you cannot use boilerplate art-of-war techniques perfected through competitor analysis. Second, emotional bonds with home-grown systems are greater and more pervasive than with third party products. Third, you are asking the prospect to make a trade-off between incremental (revenue) expenses (enhancing the in-house system) and capex (buying your product).