Posted on

iSPIRT Sales RoundTable – Startup Sales, Lead Generation, Channel Partners

First of all, huge thanks to Vizury for sponsoring great food and the premises to hold the round table. Many thanks to Aneesh, NRK Raman and Srirang for leading the session and providing valuable inputs. And of course, to all the participants for the energetic discussions and knowledge sharing.

Here are the key takeaways from my notes.  Please note that there are several nuggets of practical advice based on the experiences of the session leaders and the participants, and not just standard text book stuff. It was a great learning experience for me and I hope I can pass on some of it to you.

While we touched upon a lot of topics, we spent considerable time on startup sales, channel partners and selling to geographies outside India, and lead generation and qualification.

Read on to know more.

Startup Sales and Hiring Salespeople 

Best guys to sell during early stages of the startup are the co-founders themselves, even if they don’t have sales background.  Initially, you will stumble, but you will learn and figure out what works for you.  If founders cannot sell the product in the first 1 or 2 years, then you must seriously evaluate the viability of the business

Once you’ve made the initial sales yourselves, then you put in a structure. External sales guys need to have conviction in the product to sell it.  That will be lacking during the early stages of the company – but founders have that conviction.  Hence founders can sell better during the early stages.  One participant mentioned that for the first 3 years, he and his co-founder were selling and only later they looked at a professional sales person.

Getting the first reference customer is always the toughest part. One you have a reference customer, momentum will build.

Hiring an external sales guy is not a good idea at the beginning.  Identify folks from engineering and customer facing teams who have the aptitude or inclination to do sales and ask them to lead Sales.

Culture fit is very important in a sales person. Also, check if the person has spent 4+ years in a single company – that shows that he has been delivering results.  Sales people should also be pushing back to you.  This shows that they are getting feedback from the field and are informing you about market situation.

It is a good idea to raise investor money to scale up business development.  Investors are willing to invest in this once the product has been validated and you have a few customers.

You need to experiment to figure out what works for you. For example, for a company that made trading software, an ex-trader worked great as a salesperson instead of a seasoned sales guy, because the ex-trader was able to relate to the customer.

The sales person should have hunger and also have a good history of past successes.  Consider the age of the sales person too – in some industries, an older person might work better as the customers expect to see maturity.

Like pair programming, “pair selling” is also a useful thing to try.  This helps in DNA match, culture fitness.  Some companies have paired an account manager or a product manager with the sales guy.

In complex sales where there are multiple stakeholders from the customer’s side, ensure that you sell individually to all the influencers.

You need to pay close attention to how the customer buys.  Branding and marketing engine is also very important in “creating a desire in the customer to buy”.

Channel Partners (local and global)

When creating partnerships (in the context of channel partners and resellers) globally, be careful what works and what does not in that culture.

In general, partnerships work well outside your headquarters and you can have multiple non-exclusive partnerships.  People like to do business with a local person.

Look at the credibility of the partner.  Is the partner knowledgeable and up to date in your domain?  For one company, partnerships worked well in Brazil, but did work very well in Europe.

When you set up an office in other countries, you need to be aware of the labour laws regarding how easy/difficult it is to fire non-performing employees, taxation, accommodation etc.  Going with a partner alleviates all of this to a great extent.  However, you need to have someone from your team who is responsible for managing partnerships.

Remember that the main motivation for the channel partner is money. So make sure there is enough for them so you have their mind share.  Even if that means that the channel partner makes more money than you.  Initially, you need to be very involved so the partner tastes success. For example, you need to generate leads to the partner, go along with him to complete the sale and let him make the money from your efforts, initially. This will get them excited.

Similarly, if you want to have sales offices or channel partners in other locations, encourage well performing sales folks from headquarters to move to that location, stay there for a few years to set up processes, signup channel partners, hire local people and train them.

You can start by signing an MOU first and have some targets.  Then after 6 months of so, you can sign a formal partnership agreement.

One company also pays 20% of the salary of an employee of the channel partner.  Then you can have a joint business plan with your partner to set goals, metrics tracking etc.

You should look at your customer acquisition cost and consider pay a huge chunk (say 80%) of that cost to the channel partner.

While making sure that you do not have exclusive agreement with a single partner, be sensitive that having multiple partners in the same geography can lead to partner conflicts which in turn could be bad for your business.

Also, look at companies that sell complementary products. Maybe you can partner with them too so they make money by cross selling your product.

Channel partners are not really a must. If you can make your product easy to setup and use, then you can focus more on marketing, google adwords etc (e.g. SAAS models).  Also, in these models, you need to ensure that partners have good incentives as typically the ticket sizes are smaller and they don’t have opportunities to make money from “implementations”, training etc.  One company took an approach to let the partner decide the pricing in a particular geography with the agreement that a percentage of the revenue goes to the partner.

However, if the product is not easy and you need people on the field to educate the customers, you should definitely consider channel partners.

Sales Engine is similar to Engineering Engine

One of the biggest challenges faced by Indian product companies is that the founders do not have a sales background.  Our ecosystem has evolved to a point where we can build great products, but lack the sales acumen.  There was consensus among the participants that sales is much harder than engineering. Engineering, while no doubt hard, is still manageable.  We know the inputs, outputs, risks and mitigations with a high degree of certainty.  Sales is a different beast with lots of uncertainties.

Srirang guided us to treat the sales engine also similar to the engineering engine.

The three pillars for the Sales Engine are (a) People, (b) Processes and (c) Technology.

People: Competencies, Incentives, Org Structure.  As in engineering, there can be a magnitude of difference between an average sales person and a good salesperson.  So hiring the right candidate is very important.  And you have to set up the correct incentive program and org structure to ensure motivation and excitement in the sales team.

Processes: Strategy, Execution, Metrics.  Again, as in engineering, you need to define the strategy, the execution plan (who does what) and what metrics you are going to use to measure execution. 

Technology:  Enablement, Communication, Monitoring.  Sales team needs to be enabled.  For example, ensure flawless demonstrations and training to the sales people so their selling experience is smooth and they focus on the customer.  Use the right tools (e.g. Excel, CRM, SalesForce) to track and monitor their activities.

At different stages of the company, you need different kinds of pillars – which means you need different kinds of sales people, different processes and different technologies.

Lead Generation and Qualification 

The classic sales process consists of five stages:

  1. Lead Generation.
  2. Lead Qualification
  3. Relationship building
  4. Solution design
  5. Negotiation and Closure

Depending on the kind of product, some of the later steps might not be relevant, but lead generation and lead qualification are of primary importance.

Focused lead generation is better than generic lead generation.

Some companies have used databases of leads to generate leads and have found it useful for mass email campaigns.

LinkedIn is a good source to connect with prospects (with premium account, you can send InMail too).  After connecting, you can then try to have a call/skype to show your value proposition, if there is interest.

Someone mentioned that LinkedIn Ads worked for them.  On Google adwords, there were mixed reactions.  Some say it is costly, but it helps to put the word about the product. Google adwords can generate a lot of leads, but people also noted that there was a lot of churn from these leads (in the context of SAAS based business).

If you have a horizontal product, make a vertical offering. Your campaigns have to industry specific and you should talk their language. Customers are looking for a reference customer they can relate to.  This produces better results than targeting all verticals with a horizontal positioning.

Metrics is very important in the sales engine.  You must be measuring and tracking customer acquisition costs. And track them at various stages of the sales funnel.  For example, let’s say you generate 1000 leads, out of which 600 are then qualified, 400 of them get to proposal stage, 200 get to negotiation, 150 closed and then 130 retained for renewal.  At each stage, you must count the man hours spent and put a cost for that.  This will help you improve your sales processes – particularly in the area of lead qualification as you can see what kind of leads are working and you can pursue folks who are likely to buy.

The first step is to establish Qualification Criteria. Then evaluate each lead and assign score to lead based on the qualification criteria.  Based on the score, put the lead in one of three action buckets – pursue, drop or nurture (i.e. keep warm).

Also, ensure you pay attention to negative attributes to qualify leads based on your experience and judgment – e.g. if a company has greater than 2000 employees, then they might not be suitable to your business.

Don’t take up a wrong customer at startup stage. It can be a drain on your resources.

There are three main aspects of lead generation.

  1. Publish
    1. Blogs
    2. Website
    3. Industry Magazines
    4. Whitepapers
  2. Promote
    1. Speaker in conferences
    2. Advertisements
    3. SEO
  3. Connect
    1. Email
    2. Cold call
    3. Road shows
    4. Referrals
    5. Social Media

Conclusion 

The discussions “raised awareness” and provided lots of data from practitioners.

The key thing to remember is that there is no silver bullet and what worked for someone else may not work for you. Kishore Mandyam went one step further and said that what worked for them six months ago might not work for them now!  While there is no magic wand, you can look at general guidelines and best practices from the experiences of 20 odd practitioners.

If you have any more tips or best practices, please do write them in the comments section.

Tweetable Takeaways

Best guys to sell during early stages  are the co-founders, even if they don’t have sales background. Tweet This.

Getting the first reference customer is the toughest part. One you have that customer, momentum will build. Tweet This.

Channel partners should make enough money off you. It is OK for them to make more money than you. Tweet This.

Invest in channel partners so they invest in your product. Tweet This.

Sales Engine is similar to the Engineering Engine. Tweet This.

If you have a horizontal product, make vertical offerings. Industry specific campaigns work better. Tweet This.

Posted on

What’s my next Product Going to be? A Product Ideation/Extension Toolkit

You have your first product and it’s a success. Success only brings more demand from prospects, clients and customers for features that are not yet in your product. Some of them are not interested in all the features you have in your product but seem to use only some odd features. Or they have found a totally new use for your product that you have not yet thought of, as yet! As an entrepreneur you are sitting there thinking “Why don’t they just use what I have provided them in the way I think they ought to use it?”. These kinds of reactions from prospects and clients are not only normal but indicates that you are on the right path!. All of these can be confusing for a small product start-up. However it need not be. Here’s a toolkit put together with examples seen with various start-ups and mature product companies. Think of it as a set of dimensions along which your own products can be extended or new products ideated. Depending upon the nature of your software product – SaaS or On-Premise, different dimensions for product variations, price points or delivery methods could be applicable. The advantage of this kind of approach is that it makes it a systematic process and makes sure that what you do has exemplars elsewhere, preferably ones that have been successful!

1. Product Variants based on Number of Users 

This model may be  familiar with SaaS product companies. There may be a Free Version, say upto 10 users, Small Business version for  11 to 25 users and an Enterprise Edition for 26 to 400 users, for example. Before you choose this model it is always good to put yourselves in your clients’ shoes and make sure that it makes economic sense. Beyond a certain number of users, clients always prefer a very flat discounted pricing. I speak from personal experience! We once evaluated a SaaS product for a 25 person start-up company.  Beyond 15 users, a per user model did not make any sense for us since the discounts for more users was not steep enough. On-premise software was much less expensive than the SaaS alternative. An on-premise software with an initial steep cost and annual maintenance of 16 to 20% worked out to be much better. Like us, many clients and prospects may have unused server capacity, technical people on the payroll that have extra capacity. So hosting our own software did not add any additional hardware/software/people costs for us. This is a cautionary tale for SaaS product companies that go after large enterprises or elephants. Make sure your flat pricing makes it is still profitable for you with huge numbers of enterprise users after paying for servers, hosting, bandwidth, specialized support, etc. What if this client grew phenomenally?

2. Product Variants based on Additional Features

Most are familiar with Microsoft’s Home, Professional and Enterprise editions of software products. Basic features that made sense for home use would be in component products like Microsoft Word, and Excel. Professional editions added additional features in individual products and they added additional products that made sense in an office setting. Enterprise editions were capable of a lot more and some included server editions where the product is hosted centrally. One caveat is not to leave money on the table when you have a single product and you start adding features. At some point in time, your product needs to split into basic and advanced editions and you need to make sure you get paid additionally for added features. This is a problem you face after you add features. In product management, one of the big conundrums product start-ups face is knowing when to add a feature. If one prospect or client asks for a feature, put it on a running wish list. If two of them ask for a feature, put it in the next release. If three of them ask for it put it in the appropriate product variant and in the next build! When you do a demo and a presentation of your current product, always have Upcoming Features and Upcoming Products slides and solicit feedback.

3. Product Variants on Adjacent and Associated Technologies

In software product companies, there are always adjacent and associated technologies where your next products need to be. If your consumer facing product works in a browser, it may need a mobile version and sometimes,  vice-versa. Document management products may need workflow products to go along with them. An enterprise financial management product needs sales management, manufacturing, people management products to go along with them. This is one of those areas where paying close attention to what other software are used by your users may give you ideas about your next product stops. Clients will readily tell you what other products they need to go along with the one your sold them, if you have not already found them out when they implement your product. Integration services always go along with products, especially in enterprise facing ones.

4. Products based on different characteristics/preferences of users

Not all of your clients or users will use the product the same way. Some may re-purpose features you meant for something for something completely different. As I write this, our client is using an open-source CRM system for internal workflow handling. The reason is not that the workflow features of this CRM system are very strong but because the attachments and document version handling is very strong and 90% of their workflow depends on users submitting documents for verification, validation and formal certification. User Interface skins are based completely on preferences of users and personalization. For inspiration, consumer product companies like Unilever and Proctor and Gamble are great. You can be sure that there are one or two Dove Soap products, White and Pink, that contribute 80% of their sales. They still have Dove Sensitive Skin, Dove soap without any perfume, etc. Software product variants may not be that simple but paying attention to what different types of users or usages can lead to variants that make sense.

5. Products meant for different types of markets

Different markets may have use for some common features but sometimes may need to be completely tailored for a new market. Tax preparation software for the US market may not be of much use in Europe or Australia. Or by architecting the software a certain way, a lot of the software could be reused by including a business rules component and writing different business rules for different markets. Oracle Financials has an Oracle Government Financials parallel, which may have very little in common with it!. Adjacent markets are always good to go after. What are those markets for your product company?

6. Free Trial/Free-Paid Versions

Free Trial versions may be necessary for scaling your user base initially and converting them later on. Free Trials may have expiry dates but free versions without any expiry dates can provide data lock-in. Once a client or a consumer’s data is in your software, inertia may prevent them from switching and you can convert them to a paid one at some point in time. In some cases like LinkedIn, free and paid versions can co-exist and you can still have a profitable company. The free version may have some limits and if the limits are too onerous for intensive users, they may convert to a paid version. However, it is always better to provide as many of the features you can in the free version and not make it too much of cripple-ware! The free version should be fully functional for most of the simple stuff all of your users. If minimum functionality is not there for accomplishing something meaningful, free versions will only put users off. I hated free versions that don’t tell me after I have put in a lot of data in and then I cannot print anything or do something meaningful with it.

7. Service -Product Spin Outs

Tax preparation software companies also provide tax preparation services for consumers that cannot use the software, for whatever reason. This is a good example of spinning out a service from a product. If you are offering a service you may catch yourselves doing the same kinds of activities for your customers. If it can be automated or provided as a self-service online option for a fee, may be there is a product idea in there. That can be a service to product spin out.

When your product starts to take off, it may be time to streamline your offerings and create a road map of product variants and new products. It is better to have a process and some systematic thought put into this activity. Analysis of existing users, careful attention to what they are saying and which features of your product they are using; what they want new in your product or what new products they want,  can all help guide you in creating a product family and a road map. Having a set of dimensions in a tool kit helps  a software product company mix and match whatever is applicable to them to creating and rolling out this roadmap!

If you don’t know where you are going, any road will take you there! – Lewis Carroll in Alice in Wonderland

Posted on

Leveraging Customer relationships as a Product Manager

There have been epics written on ways businesses should be:

  1. Identifying customers
  2. Acquiring new customers from competition
  3. Retaining customers
  4. Cross selling and up selling into existing customers
  5. Leveraging Customers for expanding business

For a Product Manager, who has to deal with many internal and external entities, Customer is by far one of the most business critical entities that he has to deal with. And rightly so, since it’s the customers who not only pay for your product but help in innovation, evangelizing product and most importantly give you the credibility to make the right product / business decision and the confidence to stand by it.

Every organization has different dynamics around customer management. Hence as a Product Manager, once you get into a new organization you have to feel your way into the customer management dynamics. Let’s focus on some of the common trends and techniques used for successfully getting a handle on building successful Customer relationships.

1. Identifying Customers:

One of the first and the foremost tasks is to identify the customer. There are two types of customer:

  • Internal Customer: These can be folks within in your organization who use your product or service to assist your external customer or use the product / service on behalf of your external customer. As a Product Manager you should give their voice a significant ear, since they can not only share their experience but also be a voice for external customer. Another benefit is that since they are part of your organization you can leverage them for beta testing, brain storming ideas, hand holding external customer and even for evangelizing products
  • External Customer: These are your paying customer. As a company you have made a promise to them for delivering a product / service and that must be kept. You should categorize the customers in terms of their value to the organization:
  • Revenue (current and potential)
  • Brand value
  • New market beach head
  • New geo beach head

 

2. Initial Customer Contact:

Initial customer contact is a crucial point in your relationship with the customer. Hence it is critical that you do all the necessary research on the customer account prior to the meeting whether it’s in person meeting or on the phone. The per-call prep can help you gain insights into customers:

  • Business
  • Current issues
  • Temperament

 

As part of this initial introduction to the Customer, you must establish credibility by highlighting your relevant past experiences and listen intently by being the fly on the wall. One the key things to remember is that as a Product Manager you must align and fit well into the Sales team dynamics, since they are typically the owner of the customer relationships.

3. Basic Ground Rules for Ongoing Customer Engagement:

Once your initial introduction is done, managing the ongoing customer contact is delicate balancing act. A customer managed properly can help take your product to the next level along with its revenue.

  • You must establish basic ground rules:
  • Reviewing meeting agenda with the sales team
  • Sending meeting agenda in advance to the customer
  • Follow through plan after the meeting
  • Set up meeting success criteria
  • You have to be careful not to overwhelm the Customer with long and frequent meetings since it can cause confusion and delay in reaching your goal. This is especially true when you and your Customers are geographically apart. Crisp, succinct and to the point conversation is critical for ongoing communication with any Customer.
  • Remember the Buddha story about teaching Nirvana to a starving disciple? As long as the disciple was starving, there was no way he would have been interested in learning about Nirvana. Similarly, focus on the immediate needs of your Customer before offering him advance solutions. Once you solve Customer’s immediate business problems, he will be interested in working with you since trust in the relationship is built.
  • It’s critical to set expectations when you have conversation with Customers. Typically, if you ask customers to share their pain points, they will open the floodgates and expect those pain points to be fixed immediately. Hence before asking the Customer to open the floodgates, you should make sure that you set the right Customer expectations so that Customer doesn’t loose interest and let down. No one wants to tell the same story again and again, especially if your organization is expected to fix at some point. This same principle goes for sharing product and services roadmap. You should help Customers understand that documents like these are for confidential and for directional purposes only.

 

These basic principles for managing customer interaction will vary based on geography, industry vertical, business model, company size, number of products, product life cycle, etc. But, if followed consistently will take your business to the next level by forging long lasting relationships with your loyal Customers…

 

Posted on

Enabling Product Managers to manage Product Experience

In my last post, Product Manager, or Product Experience Manager, I described the disparate features and experiences that got broken in SiteZ and made the case that product management team should be responsible for overall product experience. In the final post of this series, I will present my views on how product management team should manage experience so that such issues can be minimized or avoided. Note that I am not talking about creating initial product experience or its next version, which is a topic of itself. I will focus only on managing the product as it goes through incremental changes.

There are 3 questions that must be answered by product management team at all times (and should be asked periodically):

  1. Are we seeing all the activities we should be seeing?
  2. Are we processing all the activities we see?
  3. Are we making good decisions based on our processing outcomes?

Product Experience Contour

To answer first question, it is important to understand the boundaries of the product experience that you wish to provide, what I call Product Experience Contour. If you define this too narrowly, you will miss out on lots of user and system activities that you should pay attention to. If you define it too broadly, you will be inundated with activities that are not useful and you will be stretched thin. There are 3 approaches to draw this contour:

  1. Persona-driven: If you have created personas (a realistic and detailed description of a fictitious user who represents a category of target audience for the product), they are good starting point to define these contours. Any activity in your organization that impacts or is impacted by a persona is usually a candidate for being on your radar. For example, if I am a persona for SiteZ (someone interested in learning from experienced people, but not interested in changing jobs), the product management team needs to ensure they are plugged into what the other group is promising and offering me. Note that in this case, I may not be a persona SiteZ cares about, which is a marketing and positioning strategy.
  2. Use case driven: If you have created use cases (UML, flowcharts, long documents, whatever) to describe how user roles interact with your system, that also is a good starting point though it may not be comprehensive. You can start by looking at the alternate and adjacent flows the particular user roles can go through on your system and see if those need to be on your radar. Use cases are more constrained because they describe your understanding at the time of product creation, while persona allows for more contemporary interpretation.
  3. Data-driven: While this may be hard (depending on how evolved your data analytics team is), this can be a very useful way to draw the contour. If you are able to analyze the data available for your system for past user interactions, you should be able to enumerate user activities (along with frequency of use) that you are interested in. The problem in this approach is that if some flows can’t be completed successfully by the user, or your data capture is not comprehensive, you may not get to know about some flows.

If possible, you should use more than one approaches above to draw the contours. Usually, persona-driven is a great way to draw initial contours, validate it with the data from your analytics, and then use data-driven approach to detect new user activities that might be important to include in the contour. In my case, it is entirely possible that none of my activities were ever tagged as useful activities to track, since these are not primary use cases (except the first one – trying to register to join the chat with the guest).

Information Sources and Management Systems

To answer second question, it is very important to look at 2 aspects:

  1. Information Source: As a user interacts with the organization, information is generated at many different places. It is very important for product management to be well-connected to these sources and make sure they are getting the information frequently. A few of the sources are:
    1. Data Analytics: As mentioned above, data analytics is a great source for information and must be harnessed properly.
    2. Direct User connect: There are many ways to connect directly with a sample set of users and keep learning about their experiences from them – product blogs, twitter, facebook and other social media channels are very effective if users can stay engaged.
    3. Be the user: It is surprising to see how little product managers use their own products on a regular basis. While being your own user may not be the greatest way to design a new product, it is a great way to keep tab on how things are going. Depending on the product, product managers can enlist their family and friends to be regular users and give feedback.
    4. Other departments in the org: Many departments interact with the users Product Managers want to know about, so it is very important to have a good flow of information from these departments. Typically, Marketing, Sales, Support, and Training teams can have good information about the user that should be captured.
  2. Information Management Systems: How information is captured, stored, and disseminated is very important for effective processing. Most activities can’t be processed in real time. Processing can mean many different things – I mean it in the sense of understanding, clarifying, analyzing, ranking and other handling of data. Product management teams need to procure, and use a management system that serves the purpose, and avoid leaving information in emails, chat boxes, whiteboards, or in their minds.

Good Decision-Making Process

To answer 3rd question, we need to make sure we have a good decision-making process in place which is used all the time. A good decision is a collaborative effort, and it is a process rather than a moment. It requires lots of data (which your information sources and management systems can provide), and it requires following a rational decision-making process. Such a decision-making process has following characteristics:

  1. Right stakeholders in the decision-making are identified.
  2. Participants are contributors and idea-providers, not spectators.
  3. Decision-making criteria (how will different options be ranked and prioritized) is defined before solution options are figured out.
  4. Personal responsible for the decision (and its consequences) is clearly identified (and it must be a person, and not a group).
  5. Once the decision is made, it is communicated, along with the rationale for making this particular decision.

In this context, since we are talking about incremental changes to product, the decision-making criteria should be known upfront and should be applied consistently. Impact of a change needs to be validated against all the known implications to the personas we care for, and this should be a key data in the decision-making process.

Evangelizing Product Management role

Even when you have great answers to the questions above, it is important to enlist the support of rest of the organization in keeping product experience awesome for the user. To do this, product managers need to be product evangelists who go out and talk about the product and their role as the guardian of product experience, to whoever cares to listen, and whichever platform they find. Once enough people in the organization realize that they should talk to you whenever they think about tinkering with the product experience, you will have created the strongest source of information about user activities and your product will thrive.

One final time, let me go through the list of issues, and show how they could be caught if above is done well:

Issue Solution
They misled the user about the time it takes to register. Evangelism would make sure they talk to product team, and good decision-making process would ensure that either advert is corrected, or product is fixed.
They didn’t allow the user to abort the registration attempt gracefully (which left the email address behind and created rest of the mess). Good decision-making process would ensure right prioritization, and if feature is not prioritized, user is provided enough information about what to do in this situation.
They were not forthcoming about who is sending me these spam emails (the email address was hidden with a display name that was the advertiser’s). Being connected to user (or enlisting friends and family as users) might flag the mail as inappropriately crafted (you are receiving this mail because.. line should be at the top somewhere).
They exposed a feature to me (unsubscribe) which didn’t work Good decision-making process should ensure that an alternative exists if this feature is not going to be implemented, and that user is told about it honestly
They didn’t give me an easy way to delete my account – emails bounced, UI didn’t have a button to delete, etc. Good decision-making process would ensure right prioritization, and if feature is not prioritized, user is provided enough information about what to do in this situation.

To be fair to SiteZ, it is hard to do all this because these are elements of organization culture and everything can’t be written down as a process and followed. Also, it is entirely possible, that they are indeed doing all this (though I highly doubt this!) and still I became a victim. Such caveats aside, I think this is a good discussion about product experience and hopefully companies will focus more on product experience than what they do today.

This concludes my series on Product Experience Management. I look forward to your comments and thoughts on the topic.

Posted on

SMBs and Indian Software Product Industry: Intertwined Fortunes

A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty. ― Winston Churchill

Small and Medium Sized Businesses (SMBs), the growth engine of India, are on the threshold of a tremendous opportunity. Globalization of trade and the rapid proliferation of computing and communication technologies are affording them a platform to expand their reach to national and global markets and compete head-to-head with global players. But on the flip side, those SMBs that do not recognize and capitalize on this wave quickly are likely to be swept away by the stiff global competition. If SMBs are to successfully counter global competition in their own backyard and elsewhere, they need to adopt software technology on a large scale, enabling them to run their businesses efficiently and effectively. But, few SMBs have the financial muscle or the technical know-how necessary to implement customized software solutions. Therefore, the majority of 13 million SMBs would count on standard business application software that requires minimum upfront investment and ongoing maintenance, to fuel their growth. Such software is distinct from the software deployed in large corporations and I refer to this as ‘Small Business Application Software (SBAS)’ to distinguish it from large enterprise application software.

Business application software (SBAS) such as accounting software, ERP, CRM etc., offers multiple benefits to SMBs –

  • As shown by research, SBAS significantly enhances the internal productivity of SMBs as well as their ability to manage relationships with vendors and customers, leading to superior firm performance.
  • It forces SMBs to adopt standard processes and best practices, moving them rapidly up the quality and value curve.
  • Most important of all, by streamlining day-to-day operations, it not only frees up the entrepreneur’s time for strategic planning but also assists her with the tools needed to make informed strategic decisions.

 

The question now arises – How can Indian SMBs get the right fuel for their growth? This is where a vibrant Indian software product industry plays a critical role. Indian SMBs cannot realize productivity and performance gains from software that is designed for developed markets. This is because the business environment in India (and other emerging markets) is substantially different from that of developed markets. It is volatile, with frequent regulatory changes, and rife with institutional and infrastructural challenges. For instance, there were 340 updates to Indian tax laws last year. That’s more than one tax law update every business day! Therefore, SMBs need software products that can buffer them from such volatility and help overcome the challenges associated with operating in this unique and dynamic environment. This is possible only when products are designed specifically for the Indian SMBs – and this is best done by a strong indigenous software product industry.

Indian software product companies are better positioned than foreign firms to support the Indian SMB market. This is because,

  • They have lower cost structures which allow them to meet the stringent price-performance expectation of Indian SMBs.
  • Further, because of their familiarity with the operating environment, they can build effective channels to drive software awareness and adoption among Indian SMBs- remember that Indian SMBs are more like enterprise customers than individual buyers in that they expect suppliers to sell to them.

 

In summary, there is a symbiotic relationship between SMB growth and a robust software product industry in India. SMBs need the software product industry to power the next phase of their growth and make them globally competitive. At the same time, the Indian software product industry, having missed out on the individual productivity and communication software wave, can leverage the large SMB market in India to establish itself as a global leader in the SBAS space. In other words, software product industry is the fuel for the SMB engine and the SMB engine can drive the Indian software product industry towards SBAS leadership. By moving in lockstep and moving quickly, India can create a competitive SMB sector and a vibrant software product industry.

Posted on

Platforms and Verticals—What to Build on and for Whom

An important decision is about development and deployment platforms. If your product is targeted for a specific operating system, the choice is obvious. When the solution has to be platform neutral, or if the deployment will be controlled by you (SaaS model), then the common options are Open Source (Linux) and Java or Microsoft Windows. Always keep in mind the Total Cost of Ownership (TCO) for the customer.

Open source in theory benefits from the availability of a huge number of re-usable components and tools contributed by an army of individual programmers. While open source is technically free, limited support and inter-operability between different open source products may lead to higher cost of development and support.

Microsoft now offers free development tools to start-ups for 3 years under their BizSpark program, but licensing cost of servers and other software for product deployment, may be high.
Other issues may impact platform choice. An implementation which is tightly integrated with specific platform features and interfaces will limit your ability to go cross-platform. Conversely, leveraging the tight integration and inter-oper-ability of various servers on a specific OS can substantially increase the product’s value and ease of use.

Web 2.0 ventures and CIOs have new options to develop applications with minimal investment. Salesforce.com is promoting the platform-as-a-service (PaaS) concept, which it says represents the start of Web 3.0. Called Force.com, it enables companies to build and deploy enterprise applications on-demand without having their own infrastructure. Core business applications, such as enterprise resource planning (ERP), human resource management (HRM) and supply chain management (SCM), can be developed in just 5-10% of the time that is normally required for custom development, and deployed almost instantly.

Your OS decision should be driven by business potential. If a specific platform dominates or is acceptable to a majority of your potential buyers, then opt for it. Spend your engineering bandwidth on providing maximum compatibility and inter-operability with other applications on this OS, to improve total value to clients.

Posted on

Stop Imitating! Finding India’s True Self

A man with a severe tooth ache goes to the dentist, who upon examining the tooth, assures the man that the problem wasn’t anything serious and that a simple procedure performed under a local anesthesia would help repair the damage. Upon hearing this, the man gets very upset and  tells the dentist, “What? Local anesthesia? You think I cannot afford a foreign one?! I demand an  imported one!”

I heard this tale first some decades ago and it served to highlight, in a tongue in cheek manner, the Indian’s obsession with all things foreign while also showcasing the lack of awareness of what a local anesthesia was.

This obsession with the imported and  the foreign should have lessened, one would have imagined, after over 20 years of economic liberalization. Yet, Chidanand Rajghattta writing about Ang Lee winning the Best Director Oscar for “Life of Pi” in the Times of India – Feb 16th 2013 – had this to say “It was a big moment for Lee, but a bigger moment for his Indian fans when he ended his acceptance speech with a “Namaste”” Really? Indians felt pride, according to the writer because Ang Lee said “Namaste”?!

There’s a big lesson for Indian entrepreneurs. A lesson involving self-esteem, capability, the confidence and courage of one’s own convictions.  An entrepreneur cannot solve problems by just seeking inspiration, affirmation and trivial acknowledgement from elsewhere without the passionate driving  self-belief, a deep understanding of the problems to be solved and a gathering of insight.  Therefore, blindly copying models from elsewhere, by only reading about startups and startup ecosystems  in  advanced economies and  thereafter slavishly attempting to adopt those offerings and even behavior  without adding any real original material of one’s own is a recipe for tragic disaster. Imitation is the best form of flattery, and indeed homage, to the original; the imitator is, at best, tolerated but never respected for there’s no original contribution on offer that’s worth recognizing, just a momentary quick-fix solution. Many companies and entrepreneurs – even countries (think Taiwan and China) – start off imitating but then, the successful ones, move rapidly to invest in creating the infrastructure to develop the insights and then execute relentlessly to offer unique solutions to their problems.

Shekhar Gupta, Editor in Chief at The Indian Express, talking to Steven Spielberg is quoted thus “Walking down Champs-Elysees, I was very happy to see a hoarding for an Indian film which described the director as India’s Tarantino”.  So, what about an American director being described as America’s Anurag Kashyap? When will that happen? Should that happen and is that a desirable goal? What will it take to make that happen? So, rather than have debates and discussions around these questions, we bask in the pitiable glory of being second hand?

Shekhar Gupta goes on to say, “I would like to express a wish to you. …… So why don’t you come to India and do an epic on anybody—Buddha, Ashoka, Chandragupta, Akbar, Gandhi, Nehru—we have many themes and stories for you. But it needs a Spielberg to come and do justice to it.”

And how does Spielberg respond?  “I think it needs an Indian director to tell those stories and maybe I could help in the background” How big a tragedy is it when we are so eager to outsource the telling of our own stories and history? What does it say about us? What does it reveal about our lack of self-belief, the infrastructure, the competence, the capacity?

Since we learn and react only to what outsiders have to say, perhaps the following will be instructive.

Eric Schmidt, Executive Chairman of Google, on a recent visit to India said “The most striking Indian internet ……….. will come from Indians solving local problems. We know that India’s internet infrastructure allows Indian engineers to solve the problems of small businesses in other countries. If India plays its cards right, we’ll soon see Indian engineers and Indian small businesses tackling Indian problems first, then exporting the solutions that work best.” For India to play its cards right, it must first recognize that it has the cards and can learn to play its own game!

Drew Olanoff writing in Techcrunch on recent visit had this to say “If a country like India can stop worrying about being like Silicon Valley and find its true self, there could be a new RedBus every other week. It’s moonshot thinking, of course, but that’s what it takes”.

Finding its true self  – that’s a challenge for Indian entrepreneurs and for those involved in the growth of the Indian entrepreneurial ecosystem. Shall we all rise to the occasion now that there’s endorsement from outside?

Posted on

Quick Research / Usability Methods: Heuristic Evaluation

(Post 2 of a series on quick research and usability techniques. Start-up’s can use these techniques fairly easily to connect to and understand their end users better, as well as maintain usability standards on their products.)

In my last post, I introduced a discount usability engineering method called the ‘Expert Usability Review’ – A method best suited to start-up’s who have access to skilled and experienced usability / design professionals who can conduct a Usability Review.

Post 2 introduces a related technique called the ‘Heuristic Evaluation’.
Start up’s that don’t have a usability / design team in place, can start focusing on usability and ease of use, using the ‘Heuristic Evaluation’ method – A method with similar goals to the Expert Usability Review, but a relatively easier starting point for novice researchers.

In a Heuristic Evaluation (or Heuristic Review), the reviewers identify issues by looking at an interface in context to a pre-decided set of heuristics. Violations to any of the heuristics indicate non-compliance / potential usability issues.

‘Heuristics’ are rules of thumb – Broader than design guidelines, typically available as self-sufficient ‘sets’ (e.g. Nielsen’s 10 Usability Heuristics / Gerhardt-Powals’ cognitive engineering principles) that can be used standalone / along with other sets.

Popular examples:

Visibility of system status: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. (Jakob Nielsen)

Reduce uncertainty: Display data in a manner that is clear and obvious. (Gerhardt-Powals)

The set of heuristics used act as a guideline – making this method more of a check list based audit rather than requiring reviewers to intuitively identify issues by drawing upon a deep knowledge of usability and UI in general.

(More about the technique and how to conduct Heuristic Evaluations at Usability.gov, Smashing Magazine and the NN Group)

One of the drawbacks of the Heuristic Evaluation method, is that the issues identified are dependent on the list of heuristics used. So if the set of heuristics is too narrow, there is a chance of some issues going unidentified. On the other hand, if the list of heuristics is very large, the review would take a very long time to do.

The most popular set of Heuristics are Jakob Nielson’s 10 Heuristics. However, these are broad guidelines – and may be too abstract for a lay person to interpret and apply.

10 Usability HeuristicsThe 275 Web Usability Guidelines from User Focus are more literal and therefore much easier to understand for the lay person. Moreover, these guidelines are available in a neat Excel spread sheet format that includes instructions on how to use them and an auto-calculated numeric rating for guidelines compliance.

275 Web Usability Guidelines


 

To end, here are a few tips you can keep in mind while attempting to do a Heuristic Evaluation:

Start with a Knowledge Transfer
Before critiquing a product, it is important to understand its context and usage.
The knowledge transfer must enable a good understanding of the product strategy and goals, target audience, known trouble points, constraints and design centres. The KT must include a walkthrough of all features, screens and task flows that are critical to the product.

Define the scope of the review
While this is not necessary for a simple product or a product with a manageable number of screens, in a complex or large product, defining the key task flows and screens to be reviewed is important to keep the review manageable.
With some exceptions, the 80 /20 rule is a good way to do this – Attempt to review 20% of the product features that are used 80% of the time.

Select the set of heuristics that are right for your product
There are plenty of heuristics available online.
Keeping n mind the product you plan to review, it is important to decide whether to use a generic set of heuristics (Like Jacob Nielson’s 10 Heuristics / User Focus guidelines) or whether domain specific / niche heuristics would be more effective. In niche or highly targeted products (products for senior citizens, children, disabled users, mobile phone hardware etc.) generic heuristics may be ineffective for unearthing all issues.

Select a set of heuristics that are right for the reviewer
The reviewers who are going to be using the heuristics, need to be comfortable / familiar with the heuristics in order to interpret and apply them effectively.

Focus on issue identification vs. recommendation
A common tendency among newbie reviewers is to jump right into fixing the problem / wording the issue as a recommendation. It is important to keep the Heuristic Review focused on issue identification, in context to a given set of heuristics. In fact, an issue may / may not be accompanied by a corresponding recommendation – Issues are sometimes too complex to be tackled by a quick written recommendation and need a larger, more focused redesign effort.

Rate issues to help prioritize
Doing this helps focus the post review effort of addressing the issues identified through Heuristic Review.

Are you a design thinker evangelizing or facilitating user research and usability methods within your start-up?
We would love to hear about your experience / answer any questions that you have about the methods that you used.

Post 3 coming up soon, will showcase a Guerrilla Research technique – Remote Usability Testing. Look out for this post to learn more about the method and to compare the issues found through Usability Testing, against issues identified through the Expert Usability Review.

We invite members of the start-up community to volunteer their screens / functions for use as examples in upcoming posts showcasing additional research techniques. Email me  at devika(at)anagramresearch.com to check whether your screen is eligible for selection.  

Posted on

Where is Dropbox headed?

Having started in September 2008, Dropbox today is a leading cloud storage provider (CSP). It has over a 100 million signed free users and about 4 million paid users (4% conversion rate as quoted often by Houston). Assuming the lowest payment tier (100GB at $99 per year), this translates into annual revenue of about $400 million. Based on Amazon S3 costing and estimates of Dropbox employee costs, the EBITDA works out to $250 million. Its costs are always going down and its revenues are always going up. The company is valued at $ 4 billion. Dropbox is making money hand over fist. Right? But consider this –

It now has more than ten competitors several with deep pockets e.g., Amazon CloudDrive, Apple iCloud, Google GoogleDrive, Microsoft Skydrive, Box, Spideroak, Ubuntu One, MediaFire, Mega.  Its other competitors, purely in enterprise space include HP Cloud Objects, Rackspace etc.

Dropbox offers the smallest free quota – 2GB plus referral bonus. All its competitors offer 5GB or more (Skydrive -7GB, MediaFire and Mega – 50 GB).

Dropbox pricing is probably the highest ($99 for 100GB). For same capacity, competitor prices are much lower –CloudDrive ($50), GoogleDrive ($60), Skydrive ($50). Box ($480), iCloud ($160). Spideroak ($100) have a higher pricing but have more powerful features (see below).

Dropbox is merely a folder service. Its competitors have other value-adds and lock-in mechanisms. For example, iCloud allows streaming of music, apps, books, and TV shows you purchase from the iTunes store, Google and Microsoft have GoogleDocs and Office WebApps respectively. Documents created through these apps do not count towards the drive quota. Box is designed more as a business-collaboration and work-flow solution that a CSP. SpiderOak is the only service that offers data encryption before your data hits their servers. Perhaps, acquisition of AudioGalaxy should enable Dropbox with music streaming feature.

The  giants like Apple, Google, Amazon and Microsoft see storage as a way to lure customers into their respective cloud and then “upsell” them on higher-level and more profitable services that they have in the portfolio. They have been aggressive in launching or responding to price cuts from competitors. Dropbox cannot win against these Goliaths in the theatre of feature and price wars.

The Dropbox differentiator was the near seamless experience backing up and syncing files to cloud on multiple platforms. That differentiator is rapidly evaporating with the competitors catching up. Moreover, what happens if all your files are already in the cloud for example music (iCloud, Spotify), Documents (GoogleDocs, Office 365), Pictures (Instagram) and so on. There are umpteen such scenarios that make Dropbox redundant.

I am sure Dropbox product managers are having sleepless nights. Do you have a product strategy and roadmap for Dropbox’s future?

Posted on

Why #Hashtags are the future of monetizing social media

You can’t invite people to a party and try to sell them stuff. Pretty much every starry-eyed startup that went after eyeballs gets it by now. Over the last seven years the web has moved away from a consumption medium (think NY times) to a creation-consumption medium (think Twitter, Facebook). But we’ve been very tardy in reshaping business models for this new model of the web. Interestingly, the solution to this monetization problem may lie with a small insignificant key on your keyboard. Read on.

Why are we failing at monetization today?

Traditional online media worked on a Pipe model, targeted only consumers and got away with monetizing eyeballs. Social media works on the Platform model, supports both creators and consumers, and has tellingly failed with trying the same old monetization strategies. 

Media Monetization 101

The monetization of any form of media is driven by mining of context and using that (or some other consumer action) as a proxy for intent. Advertisers then pay to have their ads matched with the right intent. Here are a few examples:

Keywords on a page: Context E.g. AdSense

Search query: Intent E.g. AdWords

Location: Context E.g. FourSquare

Monetization works by harvesting user intent and serving messages/information relevant to that intent. The better you are at harvesting intent, the more effective your monetization is going to be. 

Why is this model breaking down?

Mining context and intent goes for a toss in the world of social platforms. Users are the new content creators and content isn’t necessarily structured. With the older media model, the content creators (typically the media houses) were creating content to cater to search engines. The content was designed for text mining algorithms right at the point of production. With social media, the creators of content (all of us) don’t care about structure. In fact, online conversations are getting more unstructured by the day. Consequently, mining these conversations for context and intent is a crazy task, riddled with false positives. And false positives always lead to spam.

This is why the Hashtag is so important to the future of the web. 

Enter the Hashtag

Engineers would like to be known for the tech innovations that they engineered but Chris Messina will probably go down in history as the guy whose random blog post helped structure a new era of media. In a 2007 post, Messina suggested the use of Hashtags for the first time for Twitter.

This week, Facebook rolled out Hashtags.

It’s interesting to revisit that original blog post and figure out how Platform Thinking is so rare (and important) and how most of us just prefer to think in Pipes. 

Hashtags and Platform Thinking

If you think of media as a Pipe where content creators create stuff and push it out for us to consume, the content creator takes great pains to structure the content. Every piece of content will be carefully drafted in a category, will be peppered with keywords for search engines to gobble and will be structured so that the context can be easily mined.

If you look at the proposals from Stephanie and Brian, they advocate the use of pre-defined groups to regulate conversations around certain contexts. This is a typical Pipe Thinking model. Provide the constraints and force the creators to work within those constraints. It works very well when media is created within the boundaries of a firm.

When media is created by users, as it is today, one cannot afford to think in terms of constraints anymore. This is where Messina’s advocacy of the Hashtag is so brilliant. If you’re thinking in terms of Platforms, you’d want to make the creation process as easy as possible for users, yet ensure that they leave you with enough hints around intent and context. This is what Flickr did when it allowed users to tag pictures instead of forcing them to fit pictures into pre-defined categories. This is what Messina advocates in this post when he argues against users having to operate within groups and allows users to define context and intent on the fly.

Through Hashtags!

Top-down classification and forcing creators to fit within categories or groups is a hangover from Pipe Thinking; an editorial view of the web. A social view of the web requires a more bottom-up approach.

If you think of the social web as a flow of information, pre-defined categories and groups limit the channels in which information can flow. Hashtags, instead, allow creation of channels on the fly to suit the needs of the information creator. 

If you’re still thinking Semantic search alone, you’re in the wrong game

When the world first saw an explosion of user-generated content, people realized that Google’s keyword and link-driven approach to ranking information wasn’t going to work forever. Semantic search was hailed as the next savior.

I have nothing against semantic search. I just believe algorithms are still fairly limited in mining human intent from unstructured conversations. And the web is gradually, but definitively, moving towards unstructured conversations.

The solution to mining unstructured information doesn’t lie in creation of more sophisticated algorithms alone. It lies in, first, solving the problem at the point of production and allowing the new creators to easily append some structure to the information.

That is exactly what the Hashtag does!

If you’re building a platform that enables and promotes unstructured conversations, and you want to go beyond just being a communication tool, to creating a corpus of sticky content, hashtags can help transform unstructured conversations to structure, right at the source.

Tweetable Takeaways

Hashtags are the new keywords, and the key to monetizing social media.

Tags are the new categories, hashtags are the new keywords!

This article was first featured on Sangeet’s blog, Platform Thinking (http://platformed.info). Platform Thinking has been ranked among the top blogs for startups, globally, by the Harvard Business School Centre for Entrepreneurship

Posted on

8 Truths why IT Services Organizations cannot do Software Products

The bread and butter of the Indian IT Industry has been IT Services.  IT Services, as the terminology implies, is servicing a customer.  A customer states his needs, the IT Services organization makes a proposal to develop / maintain / re-engineer / etc., and the deal is done.  As offshoring and outsourcing has matured, customers have become savvy and are putting pressure on IT Services Organizations to compete more aggressively, provide more value and make cheaper proposals with no hidden costs to customers.

IT Services Organizations are in turn looking for ways to improve their margins by creating their own Intellectual Property (IP) and some of them have turned to building or investing in software products.

This articles core purpose is to warn leaders in IT Services Organizations – “DON’T BUILD SOFTWARE PRODUCTS”.  But success makes one arrogant, so I suspect some leaders will still build their own products, in which case hire somebody who has made these mistakes before and is familiar with the 8 Truths.

TRUTH 1: Trusting your best IT SERVICES Manager to build your Product

When an IT Services Organization decides to do Products, it is one of their significant investments and guess who they put in charge of it – one of their better managers.  A manager in an IT Services Organization is an expert at – scope management, cost management, SDLC, resource management, status reporting, financial management, etc.. And of course he is very good at managing other managers.

Building successful products has little to do with the above skills.  Building successful software products requires the ability to provide vision for the Product, ability to work with changing customer and market needs, the ability to build and trash architectures, deal with failures, inspire creativity, identify opportunities you had not seen before.

Most importantly, if you decide to build software Products please find a Software Product Head who has a couple of failures under his belt.  And if you find one that hasn’t yet failed, guess what – he will fail on your Software Product !!!

TRUTH 2 : IT SERVICES ORGANIZATIONS serve Customers and their Projects

The real expertise of a successful IT Services Organization is Scope Management – negotiating successfully with the customer on agreed scope and what is not in scope.  If you are the Program Manager and your team is on the wrong track or if you have made a mistake, you are taught to revisit the scope.  Examine the scope document with a fine toothcomb to compare what the customer asked for with what you have delivered.

If the customer says “The system is not easy to use” then examine the scope to say “Yes, but we did not agree on usability guidelines”, so if you now need “Usability”, it’s a change request and please Mr. Customer, do pay for it.

If the customer says “The system is too slow and it takes 45 seconds for my Employee Screen to come up” then examine the scope document for “Performance Requirements” and tell the customer “Oops !! Mr. Customer you seem to have missed defining Performance Requirements” and what you are asking for is a major redesign.  Guess who’s gonna shell out big bucks for it?!

Customer: “The database design is bad”.  IT Service: “That is not a deliverable as per scope”.

Customer: “The coding guidelines are poor”.  IT Services: “We follow our organization standard guidelines, if you need anything different it’s not in scope”.

… and so on.

Importantly, the cost of changes and mistakes is either borne by customers or at least shared by them.

In the Software Product world there is limited Customer defined scope and there is no fallback position to ask a customer to pay for mistakes.  If you have got it wrong, bad luck. Do it again and by the way do it better.  And please meet “implicit needs of the product” – customers implicitly expect a Software Product to load within 5 seconds and the usability to be impeccable and intuitive.

This is a culture shift for an IT Services Organization.

TRUTH 3: IT SERVICES ORGANIZATIONS don’t know when to say STOP

IT Services thinking:  If we got it wrong, lets change the manager, lets change the technical architect, lets change the Business Analyst.  Or better still … lets throw more people at it, lets change the location of development, lets get more funding.

How about just stopping and starting again.

IT Services Organizations just don’t know how to stop or setup metrics to stop.  IT Software Products have high failure rates – over 80%.  The IT Services Organization is used to 80% success rate.  It’s a another  culture shift.

This is also related to how Software Services Projects and Software Products are funded.  A Customer Services Project even if gone bad often continues to be a revenue earner, till the customer decides to stop development.  An investor in a Software Product organization often invests in multiple Product companies and has clear criteria to continue or stop.

In Software Products there is little room for carrying baggage and making incremental changes.  If you have got your product wrong, throw it away and restart or just stop.  Any kind of incremental changes cost a lot and makes the whole team slower.  Your technical team also knows they are building an elephant which will not be nimble, flexible, easy to change or responsive.  There is no greater demotivator than a technical team that doesn’t believe in the Product.

A Software Product is developing IP for the future – there will be peaks and troughs of investments and returns and these will typically be in separate time-cycles.  This is another reason, why an IT Services organization just doesn’t know when to say STOP.  They may well invest much more than a pure-play Software Product Organization would and that too for poorer returns.

TRUTH 4: IT SERVICES ORGANIZATIONS have Forgotten how to BUILD SOFTWARE

IT Services Senior leadership is chosen for Customer Engagement skills, for P&L responsibility, and not for Product vision.

If you are in IT Services, when you resource for a Customer Services Project, you pull out your Gross Margin sheet and see what level of senior / junior people you are allowed.  You then go to your Resource Management team to help you fill those resources.  You could need a team of 20 or a team of 200, depending on the size and complexity.  And that is your focus.

When you develop a Software Product, you first review the market of the Product, then you review its features, then you validate it with some customers, then you do prototypes and proof of concepts, then you validate it again with customers.  You convince an anchor customer.  Your entire focus is on – are the features right, is my customer happy, is my software maintainable, will I get references to other customers?  Resources and budgets are just as important but features and benefits to customers come first.

When a Software Product organization scales the problems grow differently – what is the scope of my product, what are the analysts saying about it, how will my licensing model work for small and large customers, how will I support customers, what is their upgrade path,  are there core architectural bottlenecks that will prevent the software from scaling?

The priority for an IT Services Organization remains quality of service, size of business, revenue and margins as it should.  IT Services Organizations do not know how to build software any more.  They knew it once – now they have forgotten.

TRUTH 5: IT SERVICES ORGANIZATIONS’ HR works on scale and size.  They cannot focus on the problem of 1 Employee

The HR team of an IT Services organization has a very clear idea of where and how to recruit, what compensation to give, how to give raises, how to be fair across thousands of people.    There are employee benefits, training programs, career growth plans, dual shore movement, etc.

Product teams start by being small teams.  They often need expertise in small bursts – speed is everything.  An IT Services Organization just doesn’t have the flexibility and nimbleness to take care of the needs of a Product team.  Can I out price my 1 core architect and 2 functional experts?  Can I provide them with ESOP that is way beyond others on the services side?  Can a developer in the product space get paid more than a manager?

Can HR deal with the above?  More importantly does HR have the mandate to make such exceptions?  What happens when a Product person moves to a Services Project – how do the incentives work?

For a services organization with thousands of people – it is not significantly important to solve the problem of at most a few hundred people working on products.  For the Product Organization every decision MUST be driven towards getting a great piece of software to the end-customer.

IT SERVICES ORGANIZATIONS don’t know their TOP DEVELOPERS

A developer in a software Product organization is the go to person to solve any problem.  It is extremely unlikely that a Services Organization even knows their top developers.  Developers of Software Products may often get paid more, and maybe more relevant to a customer implementation than any manager.  I have seen situations where One Top Developer has by himself been able to solve a problem that 15 managers, technical leads and developers could not.

The best Product Organizations will identify and nurture these developers.  IT Services organization will struggle with salary bands, designations, bonuses, and the best ones will find workarounds to reward these developers.  But that’s just what it will be – a workaround at best.

TRUTH 6: IT SERVICES ORGANIZATIONS don’t know IP management

Providing an IT Software Service to a customer and actually being the owner of the Software Product are very different perspectives.  When you own the Intellectual Property – here this refers to the Software Product; it comes with a different set of liabilities as well.

The questions an IT Services company may not ask – Did I leave a security hole in my software through negligence? My design is faulty and my code is badly written – did I disclose this to my customers?  If one customer is going to sue me for damages, does that mean all my customers will have to be informed? What if one of your developers has copied code that is Open Source – what are the implications? Etc. etc. etc.

Also, to develop IP, requires a certain amount of R&D (loosely used term here to indicate trial and error, waste and true R&D) – which algorithms will be most optimal? Which UI will be a hit with the customer?  Which features will be used the most?  And anyone who has been in R&D, knows that investment in R&D does not guarantee results and is often considered waste.  R&D needs an open mind and the results are often serendipitous.

Services organizations are experts at managing waste and reducing fat.  The Product organization actively produces waste and a CFO or an Accountant is often looking at the Product team (within the IT Services Organization) with itchy fingers to take that number off his xls sheet.  The Product team needs to experiment, to create and to throw away;  to improve things and hone it and make it better.  It is an idea generating machine that needs focus to create more value.  It is just such a throwaway piece that a product may need to make it standout, to break through the clutter and the noise in its space.

Related to IP is also a host of copyright, trademark and patents related issues.  The IT Services Organization needs to come up to speed with all of this if it is to create software products.  The last thing you need is for your Product to be successful and then to discover that someone else is using the same name or you have been slapped with a copyright infringement.

IP is the differentiator that can make your Software Product successful.

TRUTH 7: IT SERVICES ORGANIZATIONS grow through SIZE and PERSEVERANCE

IT SERVICES ORGANIZATIONS are all about growth through replication of success.  The growth mantra for this replication of success is to scale through resources, infrastructure, deployment on projects, managing bench, engaging with customers, building competencies, delivering software projects successfully time after time after time.  There is also a huge push on sales and winning large deals.

An IT Services business is also conservative by nature.  Due to its maturity, it is also a predictable business model.  Investments are made in people after knowing the size of Customer Projects that will be won. You assign resources on a won Project and then remove them when the Project is over.  When you don’t win the projected business and have a large number of unutilized resources (bench) you either cut salary or you ask people to leave after a certain amount of idle time.

In a Software Product Organization, at the first level, the Product should be able to talk for itself.  The word of mouth is critical.  For Example, for an internet product to grow, the problem is eyeballs and retention of the end customer on your internet site.  The primary focus is not on growing the number of people you have to hire and train.  In Services deals you may lose out if you are unable to show the customer your ability to scale up and get office space, people, training, rebadging, infrastructure, etc. on time.  In Product you will need to do a flawless job of your product implementation and ensuring your product Roadmap is road worthy.   You grow through better products, with backward compatibility, with presence on mobile, with analytics – and many other features around the product along with a science to replicate deployment methodologies and customer trainings.

Both IT Services Organization and Product Organizations scale and grow in very different ways.  An IT Services Organization doesn’t have the DNA for software products.  So, if a Services Organization chooses to go for Software Products be prepared for some gene level surgery.

TRUTH 8: IT SERVICES ORGANIZATIONS are not experts in their Customers’ Business

IT Services have today moved away from being just technology companies.  A website of an IT Services organization shows you industry verticals and domain solutions.  Full credit to IT Services companies for providing such exemplary service to its customers.  However, the customer still doesn’t expect the IT Services organization to know its business better than itself.

IT Services Organizations have honed Customer Service to a fine art.  There are processes and sub-processes to be followed.  You have frameworks like ITIL that continually reduce cost of maintenance and support.  The focus is on reducing cost of Business As Usual (BAU) activities.

With a Software Product it is different.  In the domain of a particular Software Product, customers expect you to know everything.  You are expected to know the domain, the technology, competing products, integration with other systems, mapping to business processes, etc.  You are expected to know how the beginner users and how the expert users will use and misuse your product.

All Customer Service comes from the knowledge of the customers’ business scenarios and not from a support management framework.  The ability to anticipate a customers’ problems and to be able to demonstrate thought leadership are critical to the success of a Product Organization.

Conclusion

If you are an IT Services Organization the biggest mistake you can make is to think that a Software Product is just another piece of software, which it is.  But that is not ALL what it is.  It is a completely new business.  So be prepared to reinvent that part of your team or else …

Posted on

Stories are Better Than a Feature List

You’re at an event, and you’re ready. You know your product inside out. You know the competition. You know the licensing terms. The deals. The partners. The competition. Technical details. Market details. Detail details. Regulations. Strengths. Compatibilities. Your head is stuffed. Crammed, just when – A customer comes to you. “I’ve got sixty seconds. Why should I buy from you?”

You spent years learning and studying and now you’ve got 30 seconds. You choke on your own knowledge.  In this situation, has your strength, your deep product knowledge, actually become a weakness? What do you do? How do you convey so much information in such a small amount of time?  It’s these situations, when a 100-slide PowerPoint deck or a technical demonstration is not possible, when it is critical to turn to the oldest form of persuasive communication in the world – the story.

Your customers are being constantly bombarded by myriad of marketing messages as well as other communication – emails, blogs, and social media. How do you make them notice your message and remember it when making a decision? The answer again is a story. Stories are powerful. Stories propagate thru centuries without any media coverage and advertising dollars. We hear stories in childhood and we repeat them to our children. And the story goes on. Consider these two announcements from two of the biggest product and SaaS companies.

Microsoft’s Jan 21, 2007 announcement

As Microsoft continues to deliver innovations to its unified communication and collaboration platform – which includes Microsoft Exchange Server 2007, the 2007 Office system with Microsoft Office SharePoint Server 2007, and has solutions in the pipeline such as the next generation of Microsoft Office Communications Server – Microsoft’s industry partners find that business is booming.

Google’s Oct 11, 2006 announcement

Ever found yourself trading email attachments with several colleagues, trying to collaborate on a document, only to have someone chime in at the last moment with corrections to an outdated version?  Today, at the Office 2.0 Conference in San Francisco, Google launched a solution to these collaborative and document-management challenges: Google Docs & Spreadsheets

Which one do you think is easier to understand and remember? Which is stickier?  The Google announcement has elements of a story as suggested by Heath brothers in their book Made to Stick.

Technical people are horrible at telling stories. It is tough for them to move from listing technical features to telling stories. Here is one way forward – apply to your writing the SUCCES framework suggested by Heath brothers in their book Made to Stick. They say a sticky message is simple, has an element of unexpectedness, is concrete and complete, makes an emotional connect and is told like a story. I strongly recommend the reader to get hold of the book and practice what the brothers suggest.

Here’s another example from GE – look at their site.

Their lead story isn’t about the products they sell or the event they were at. At the core GE stands for innovation and they tell us about their innovations not by listing their innovations in a bulleted list with awards and partner logos attached, but by talking about their rich history, their leaders, their visions and their journey over time.  It’s a rich narrative and something we can all learn from – the products are there but it’s not their lead.

You need to create your story or others will create it for you. – What is the narrative for Apple, What about Google or eBay? What would your narrative be? Remember to make your customer a hero!

Posted on

What’s your Sales Story?

Whenever faced by dilemma over any issue pertaining to sales and marketing, I recall a famous quote by Ben Feldman, who is considered one of the best salespeople in world history.

Don’t sell life insurance. Sell what life insurance can do.

Just by following this one mantra, Ben was able to insurance policies more than worth USD 1.8 billion in his life!

It would be unfair if I don’t mention Steve jobs here. Have you ever seen him selling Apple products? No! He would always sell you the idea of ‘how apple products can change your lives’. Watch his keynotes at the launch of iPhone or iPod and you will understand what I am trying to say here. Sadly I don’t see the same approach being used by Indian startups and product companies. Many of us are still struck at ‘Buy our product, this is the best; this is different; this is cheaper; this is awesome…..’.

Human brain is inherently averse to sales. The moment we realize someone is try to sell something to us, we tend to lose interest in the pitch, become defensive and start finding reasons why we don’t need the particular product (or service). So rather than doing direct selling using plain facts and figures, if you narrate a story about your product and how it can help fulfill peoples’ dreams, chances are they’ll listen to you. Research has proven that majority of the decisions are driven by emotions and not reasons. We don’t realize that because our brain tries to find logical reasons to justify the already made decision.

So triggering those emotions should be a critical component of company’s overall Sales story. Ideally the sales story should be centered around the following,

  •          Making people more powerful/ efficient/ potent through your product
  •          Making people passionate about your company and yourself
  •         Ringing alarm bells in peoples’ minds of losing out on something if they don’t buy your product
  •         Generating mystique and awe among people for your company and yourself
  •         Being just enough rebellious and loud to make some noise and stand out
  •         Developing trust among people for your company and yourself (damn important)

 

Let me take an example. I went for a sales meeting for some stakeholders from a global networking giant. Here is what I presented the first time,

‘WE are Company X. WEhave been doing this for so many years. WE have worked with companies like … WE’ll help your business grow to next level (x%). WE’ll help to save y% costs. We’ll increase your efficiency by z%, so on and so forth’

I got a good response but not a mind blowing one. We were asked to present to some other stakeholders in the follow-up meeting. I decided to try out something different this time. Here is what I presented,

‘YOU are Company Y. YOU have been doing this for so many years. YOU are doing good with a% growth, b% cost savings, etc. YOU are projected to reach here. What if we help YOU reach there. YOUR competitors are already catching up. We can help YOU leapfrog. We have already helped many companies to do the same. YOUR company is very good, we can make YOUR it awesome’  

Boom!! Applauses all around!

Notice the ‘We’ centric approach compared to ‘You’ centric one. Research has proved that customer relations are more long-run and stronger in the latter approach. I have complemented ‘company’ with ‘yourself’ because your personal branding goes hand in hand with that of the company, as people don’t perceive you much different from your company. I can’t think of any aspect of life where you don’t have to sell anything. I believe aforementioned points are relevant in every sphere of life- job interviews, user acquisition, b-school interviews, advertising, online marketing, presentations, proposals, VC pitches, etc.

For the founders, it goes without saying that you should have questions related to positioning, value add to customers, target market segments, key differentiators, etc. clearly figured out before you start creating your sales story. Answers to these should be Crisp, Short, Tangible and Simple.

Happy Selling !!

Posted on

7 tips to build a script :: a Step by Step guide

I wish it was mathematical. But it isn’t. There are unlimited combinations when building a story. That’s what makes it so much fun to consume – you never know how the storyteller tells it… 

So instead of giving you tips in a bulleted format – let’s build a script together.

What we know (or must know) before we start:

  1. This is for a 60 sec pitch video about a product called Glitch from Triton.
  2. They sell to Hotels. Their audience is clearly marked out.
  3. What the product does has been clearly documented.
  4. We need to bring out a call to action so they visit the product website.
  5. We are selling to Hotel people – they don’t have time to consume long form content – so the video should not be soggy and heavy – it should be light and brief. This means no more than 2-3 propositions. 

STEP 1: Start with a problem

” Guests want something – you deliver. Its simple. But when this doesn’t happen – your guest will get upset and then…. she’ll tell the world about it. The last thing you’d want is to read about such episodes on Social channels. “

Your product may solve many problems – choose only ONE to start with. Choose the problem that’s closest to your customer’s customer. Your customer cares about that. 

As you can see, we get to the problem quickly. The script doesn’t teach anyone. It just sketches out a scenario that will happen when the problem arises – customers will crib about your hotel’s service.

So here’s the first tip: 

TIP#1 – Get straight to the problem. Don’t beat around the bush. 

The easiest way to do that is to think like a customer and ask yourself – WHY MY FEATURE. Think what makes sense for you (you’re wearing the customer hat mind you). Think about that exact problem it solves. And then write that problem in simple words. Be direct and obnoxious if you have to – we’ll soften it later. 

STEP 2: Lets talk about our product a little

” There’s an easier way. Triton’s Glitch. Glitch alerts you when something has gone wrong in the service. And what you had to give up to … well… sort it out…. “

Part 2 of the script talks about the product. But not too much. We’re just making an overarching comment about the product. This is the main proposition or a product ‘tagline’ if you will. 

Tip #2 – Resist the urge to start talking about features here. Instead – make an overarching statement that comprehensively explains the product. 

This is around the 20 second mark. This is the time your audience will make a decision if this problem-solution pair interests them or not. 

Tip #3 – To optimize your video – ensure that the bucket personas as close to each other as possible. In every way… 

If you know what fish are in the river – you’ll be more successful in fishing. That’s because you won’t need to change the hook after every catch – you can just add the bait and cast your line again with the same hook. 

STEP 3 – Explain the feature a bit

” Whenever a service breakdown happens – all departments are instantly alerted and the right manager meets the upset guest, apologizes and offers a compensation. “

We’re going to show how the tool will work. We’re being absolutely real. This happens and then this happens and then this happens.

Tip #4 – use real cases where your customer has benefited and use that as the central pivot to build a story. This is another technique of writing a script – where you start with a situation and come back to the overarching product tagline. 

STEP 4 – play the second trump card

“What you get at the end of the day are clean reports that mark out repeated service breakdowns and compensations spent on them – across multiple properties.” 

We play our second trump card – a business benefit around data. We’re telling the hotel people that they can track and audit their expenses. No business likes to lose money and we chose to work around that sentiment when writing this line.

Tip #5 – sometimes your product may not have a ‘reporting feature’. In this case – try to bring out another feature or proposition. For eg. – X-app can also send you instant alerts…, Y-cloud will immediately shut down ports…, Z-service will raise a ticket… This is the second trump card. 

STEP 5 – Wrap it up

“No wonder a renowned Hotelier claims 18% jump in guest satisfaction scores since they implemented Glitch. Check it out today.”

We use some of our customer conversations and pick out a data point that one of the customers mentioned. This brings a reality check to the audience about the 2 claims we made earlier – step 3 and step 4. 

Tip #6 – Nothing convinces like data. Use as much data as possible in your stories. Avoid fairy tale endings and princesses and frogs. 

Tip #7 – Though I just said don’t use fable characters – one of the techniques is to start a story with a misdirection. So use these animals to start stories – not to end them. 

– – – – – – – – –

Here are 3 criteria I consider when evaluating a script:

  1. Is there any humor in the first 20 seconds. If the script doesn’t have humor – animation should. Or the screenplay. Or the audio – something must make the audience smile.
  2. After reading the script till the end – I should be able to recollect the first line of the script – without having to go back to the script. This means the script is light and catchy enough for my mind to be able to recollect what I read a few seconds ago. The information ‘stack’ on me is small enough for my mind to register and remember. 
  3. Word limit and sentence size. No more than 150 words and as small sentences as possible.

– – – – – – – – –

 Together now – this is the script in its final avatar. 

” Guests want something – you deliver. Its simple. But when this doesn’t happen – your guest will get upset and then…. she’ll tell the world about it. The last thing you’d want is to read about such episodes on Social channels.

There’s an easier way. Triton’s Glitch. 

Glitch alerts you when something has gone wrong in the service. And what you had to give up to … well… sort it out…. 

Whenever a service breakdown happens – all departments are instantly alerted and the right manager meets the upset guest, apologizes and offers a compensation. 

What you get at the end of the day are clean reports that mark out repeated service breakdowns and compensations spent on them – across multiple properties.

No wonder a renowned Hotelier claims 18% jump in guest satisfaction scores since they implemented Glitch. Check it out today. “

Posted on

Where is my story?

Most startups talk about product features and how they are better than their competition in terms of their offerings. They really don’t tell stories, however people remember stories for long and not the facts and figures. Most often than not, people say we are a startup, we don’t have paying customers and we do not have stories to communicate. The fact that they are developing a product itself is towards addressing a market gap that the incumbent solutions are not addressing – product creation story. Why don’t you communicate that as a story?

Let me give you a couple of examples.

I was consulting one of the product startups in the education space, which provides smart classrooms. They also were communicating features, benefits as a part of their communication, but they realized that they wanted to do stories. I asked them, why did you choose to develop this product and how did you go product startups about doing this?

In fact, when they wanted to develop their product, they understood the gaps in the market and they had an idea about how to address the gap but they weren’t very clear. In order to get the clarity, they interviewed hundreds of students and hundreds of teachers from across the country before beginning to design their courses. These interviews provided them with a clear idea of the instructional methods followed and what was lacking in it. With this, they started to develop the courses and after about 36 months of work, they have more than 6000 classrooms using their product. This is their product creation story, which they started to communicate very efficiently.

They also prided themselves on the usability of their product and its intuitiveness. I asked them, what does your customer feel about the usability of your product? They said that they are completely positive about the experience. I persisted, what do your prospects who are evaluating the product feel about usability? They weren’t very sure about it. That’s when, we wanted to influence their perception and we decided to do this as a story as well.

We decided that we would not demonstrate the product to the prospects; instead, we will install the setup and get a couple of volunteers from the school to play around with the product. Once they did that, they understood the usability experience, they felt a part of the experience and they started championing the product sales, which resulted in improved conversions.  This became their usability story, which is a part of their pitch now.

These examples are only triggers for you to identify where your stories are. I am sure that this would act as a starting point for you to find your stories.