Posted on

From Bootstrapped to Angeled : Is it your idea or product ?

You’ve shaped up your business idea to flag off. You have a pool of talent believing in that idea and lined up with working prototype with feedback. Now, it’s time for funding to take your idea to concept to design to product to a successful business.

Depending on the idea, startup projects can be particularly expensive and often incur new, unforeseen costs. That is particularly true of technological ideas, which are currently in vogue but require exploratory costs (to pay experts to determine if the idea is feasible) and initial product development costs. Even if a team proves the idea is feasible, they often need to build a working model or prototype to prove that to investors, which can sometimes add thousands of dollars to startup expenses.

Bootstrapped to Angeled_To_Raise_Seed_Capital 1

The vital idea behind bootstrapping in commercial means is to borrow as minimal finance as possible. In two words, you only rely on either on your own budget and savings, on some crowdfunded amount or simply on loans from friends and family. This scenario urges you to borrow insignificant amounts of money and thus keep interest costs minimal. But as the market dynamics populates further, the wider entrepreneurial community starts delivering differing views.

Guy Kawasaki has proclaimed that “you should always be a boot-strapper… too much money is worse than too little” but goes onto to suggest “if you do get offered venture capital, take it, but don’t spend it”.

Most people focus all their time and attention on building their idea, and forget that even the coolest product or service is worthless if people don’t use it. Creating a successful product or service requires two things:

  • A solid implementation of the idea.
  • People that use it.

For the best chance of success, you need to identify the smallest core of your idea that has value to your potential users, build only that, and release it.  This “minimum viable product” or MVP serves as the ultimate idea testing ground.  It lets you build a relatively inexpensive version of your idea, test it with real users, and measure adoption.

Investors see a lot of ideas, which is why they won’t sign an NDA (your idea is not original, no matter what you think). But if you have a team that has delivered products in the past, worked through adversity, and has a failure or two to learn from, then the investor can see a group of people who will protect his investment, and has demonstrated the skills to do so.

So No. An idea will not get you funded.

To be investible, a start-up needs to have a good product-market fit and the potential to scale up quickly to a large market. It needs to be defensible with intellectual property or some other competitive advantage. And it needs to have a credible team in place, people who investors will believe can execute. And there needs to be some kind of proof, also called validation, also called traction.

Building an early prototype also helps you attract tech talent, because it gives people something to look at and play with, and it communicates your idea in a more “tangible” form. Then you can shop it around to potential technical co-founders to get them excited about your vision. If you have the means to actually build a working prototype, so much the better!

Most Angel Investors (and VCs) won’t pay much attention these days without some other sign of traction, especially because the financial and technical barriers to entry are getting lower and lower. Bootstrapped to Angeled_To_Raise_Seed_Capital 2

Additionally, the current market size doesn’t matter. The market size in 10 years is what really matters. You want to be in a small but rapidly growing market. You can change everything in your start-up except the market. So spend a lot of time up front to make sure you’ve thought through your market. “Having value” and “being fundable” are two completely different things.

Two of the most valuable things that the investor community seems to have been seeing from close quarters are: customer feedback and data from pilot research, which can enable them ask questions that lead to product breakthroughs. Angel Investors would need to know how your idea has improved to a bit more than a fledged product wireframe, so that their willingness to invest into those ideas via money, and social reach can increase to ensure that the success of your product is further defines by cutting-edge product development process.

Following guidance is thus seems to have gained ground and immovable traction for all the aspiring entrepreneurs who are progressing from a Bootstrapping channels to Angeled funding:

  • Be value-driven rather than fund-driven
  • Be independent of technologies that make you lose control over your idea
  • Make the customer a base for your product than profit
  • Base your ideas on supply and demand and not on the money it can attract

Once again, this isn’t a strict definition, but the seed round is normally used to fund the initial stage of your company where you’re finding product/market fit, and the following rounds are meant to help with scaling. That said, the road from concept to readiness (aka product MVP) is long and winding. Entrepreneurs’ single greatest challenge in this sphere of activity is balancing bursting creativity with structured, method-driven decision making.

 

Posted on

Product Manager as the Wicket Keeper

Wishing you all a very happy 2017, may you get the guts and courage to make the change this year.

Mahendra Singh Dhoni, one of the most successful cricketers is certainly an inspiration for all of us – cricket fans and Indians. While he is a famous and winning captain, probably being a wicket keeper has helped him to shape up his instincts, strategy and execution.

Being a product manager for few years now, I often relate to being a wicket keeper, who really wears multiple hats to help his team and win in the market. Often there is lack of clarity on the role of a Product Manager and why are they needed. In this post I would like to focus on drawing some parallels between Wicket keeper and Product Manager , especially differentiating the greats from good ones.

Pitch reader (Market)

Understanding the pitch is a key aspect to winning a cricket match – so is the understanding of the market to win with a product. Wicket keepers are great pitch readers, as they stay close to it always. So is the product manager, as understanding the market is a very significant success factor for products. If product managers can read the pitch (market) well, they can certainly guide the team very well to shape the right product that fits the market.

Supporting the bowler (Development)

One of the primary roles of product managers is to work very closely with development to shape and release the product. They are involved every ball, they need to be attentive to every detail, they need a great presence of mind, they need to keep motivating and appreciating every milestone. They also support the bowlers on field placements – read as key reviews of every aspect of the design of the product. They can give instant feedback and suggest changes, on the spot to ensure success. They also catch to take wickets – similar to some key contributions by product managers on prototyping and closing loop on the product.

Alert with fielders (Quality Assurance)

Wicket keepers stay alert with fielders and set an example in the field, as well as guide the field on what’s coming from the bowlers. Product managers similarly are one of the initial quality assurance /testers of the product, and guide the QA on how to ensure the quality of the product.

Close to opponent (Competitive insights)

Wicket keepers stay very close to the opponent batsman. They know whats their strength and weakness by closely following and watching them. This can certainly help share their insights to the bowlers. Similarly Product Managers have to stay very close to whats being done by competition, and how the products they build can surpass the competitor products, by understanding their strengths and weakness.

Handy batsman (Sales)

Finally wicket keepers can also support with the bat. While they are not the strike batsman, they may be useful handy batsman as they know the pitch and the opponents, and in some situations could single handed win with their extra batting abilities (like a Dhoni or Gilchrist). Product Manager similarly can support Sales to win in the market. Product managers know all the details of the product, the market and the competition – so they can certainly help win in sales. While they are not the strike sales man, they can be an effective supporting person for the striker. Some Product Managers have a very high success rate of closing business when they are involved.

There could be more parallels…but hope the above helped you understand the critical role of product manager, as critical as a wicket keeper in a cricket match, and some of the key ingredients and potential contribution they can make to your product.

When we all started playing (read startup), we may not need a full time wicket keeper as someone wears that hat in rotation, but to make it big (beyond early stage startup) you probably need one.

Great Product Managers move on to become Great Product Leaders and are winners….Adam Gilchrist or our MS Dhoni !

PS : Never thought MS Dhoni will resign captaincy when i wrote this blog post (he resigned on same day when this post was published). Anyway hoping he will continue to be a wicket keeper for a some more period, and great team player 🙂

Update on 15 Aug 2020 : M S Dhoni retires from international cricket, and the above post is a reflection of how his skills, or skills of a wicket keeper is so important, like how a product manager would contribute to a product !

Posted on

Need 9 months to get baby out

One of the pressures and challenges of working on products is to get it out soon – the release. But I often recollect one of the leaders that I have worked with saying “need 9 months to get baby out”.

9monthBaby1

What’s the right time for a product release – Some Considerations?

Build for market, not a customer

9monthbaby2

Remember products are not built for one customer, its built for several of them, for a market. I highlight this as especially in India, we have abundant  services companies and people with great experience driving innovations and solutions for one customer, and often the release time for such delivery can be done in a shorter duration as we are working towards a specific requirement set.  Its different to build it for a market or many customers in mind.

Enough research time to iterate

9monthbaby3

The other key aspect of building a product is to spend good time on researching the market, understanding user problems and figuring out what to build, before start building it. In certain cases it could also be some initial prototypes to get the thinking process going. Often this time is ignored when building products.

9 moms cannot make 9 babies in 1 month

9monthbaby4

By getting more people assigned is not the solution to get the products out faster, actually it could be counter productive as there may not be enough components that can be built parallel and also could result in confusion on co-ordination.

It’s not just about development

Many software products fail primarily because they put all the time and effort only in engineering and developing the product and do not plan for an effective early adoption and go to market (including pricing) launch time planning. They consider this as lesser important task and often consider this as a post product release activity. But the market readiness and go to market should be planned well ahead, and enough time to be allocated to early adoption and launch cycle.  The other aspect that gets ignored many a times is user empathy and design for user interaction and interface.

Focus on quality, differentiators

9monthbabay5

Bugs are fine in software, can be fixed is the typical attitude in software industry. But depending on the mission critical nature of the products, quality is going to be key criteria. Thorough testing and quality is an important part and while dates can be compromised, quality should not be compromised as the word spreads if its buggy. Get it out with good quality.

9monthbaby6

Many products compromise on features and differentiators, to deliver a product in time. This again can be dangerous in the current extremely competitive world.

So usually the right time of the release should have key focus on quality and differentiators.

Alpha, Beta….

We come across examples of products that get released to market without alpha, beta cycles – without being taken to first few customers or users to try out. This can be dangerous, inspite of the time pressures or the brutal confidence that you may have about your products and self testing, there should be time allocated for alpha and beta trials.

Rapid release cycles

9monthbaby7

The other side consideration here is that while products have to be planned, it can’t take too long as well. Many of the established players get into this syndrome where they spend too much time planning and laying it out but by the time the product comes out, the market is lost or captured by some one else. This is where agile methodology comes in handy. Products should be planned in such a way that there is minimum viable scope covered coming in from the research and there is agility built into cover a rapid release cycle post the first launch, where more enhancements can be planned, based on customer adoption.

So if you started reading the blog hoping to get the answer on the right time for a product release, sorry for disappointing you. But from my experience where I have been involved with enterprise software products that were built in 3 months, 6 months, 1.5 years, 3 years etc. , some of the above points were the learnings for the success or failure of the product. Plan time for the ideation/research, design, development, thorough testing, beta and GTM launch planning before getting your baby out…

Share your experience or other considerations that I may have missed here…

Posted on

Customer discovery meets Indiana Jones at #PNSummit

If you haven’t made up your mind whether you should be at PNSummit, then you’re probably thinking too hard.

It’s not a Conference.

It’s not a Conference.

Yes, I said that twice.

It’s brought to you by iSPIRT ProductNation. And a team of selfless volunteers who want to give back. These guys have regular companies to run. And day jobs. Putting together #PNSummit is back breaking work. But they enjoy it. Ask anyone of them if you think this is hyperbole.

Product companies at different stages have different needs. #PNSummit is styled like a bootcamp. Only, it focuses on the underserved entrepreneur. Is that you? If you’re between 9 months to 18 months old you’re probably searching for a lot of answers. But we don’t have any. All we have is a method. It’s a secret sauce that’s going to be revealed at #PNSummit Customer Discovery Hacking Day on December 4th. This sauce is cooked by Pallav and his team of cohort leaders who will take you through an entire day of… ok let me stop here.

I don’t want to spoil the fun. Not yet. This is for believers. We’re not taking in everyone who applies. It’s selective, based on your current profile. Even if you don’t make it, you’re probably very good at your trade so we’re not being a judge here. Our goal is to have similar minded people in the room, who want to learn and are eager to share. In many ways Discovery Hacking is also about discovering yourself. It’s like Indiana Jones, who never fails to surprise even himself.

Meet us in Pune this December. Only a 100 will make it, so think later, act now. You can apply here.

Sandeep Todi

Co-founder of a software product and a #PNSummit Volunteer

Posted on

The Virtual Medical Assistant – Practo.com – a cloud based service that covers over 8,000 doctors…

“Why isn’t there a place where we can store all our medical information?” is the question that bugged Shashank ND, Founder of Practo.com. Jamming together with a classmate from NITK Surathkal, they found a solution and founded Practo.com – a cloud based service that covers over 8,000 doctors and manages the records of nearly 3 million patients. 

Shashank, I was looking at your website and I was intrigued by the fact that you actually started this business because of a personal experience. Do give us an insight into how you started?

My father was to have a knee operation, and we had visited a couple of hospitals where we had some tests done and got some reports. The doctor advised based on the reports that my father required surgery. Now obviously I was concerned and we wanted to take a second opinion and have these records shown to a doctor in the US. It turned out to be a quite a clumsy and cumbersome affair. I had to take a photograph with my camera then transfer it online and then the doctor in the US responded to us asking for more information and then it suddenly struck me, if all the information was available in a secure repository that could be accessed easily 24/7 we wouldn’t have so much back and forth and delays.

But I wanted to double check things so the next time I visited my ophthalmologist I asked him to give me the prescription on email so I could keep a digital record of it. He told me that the system he used was 10 years old and didn’t support this functionality. He went on to say, if someone can give me a system like this I will gladly use it. So my imagination started running wild and I thought of a system where all our personal health records could be available digitally.

Fundamentally, we have a Facebook where we keep all our personal information, we have a LinkedIn where we keep all our professional information, I just wondered why there isn’t a place where we can store all our medical information. If you really look at it, doctors need records because they become more efficient in servicing patents. Patients are keen on information digitally stored because they don’t have the hassle of storing stuff physically as it is also subject to wear and tear. The problem was really the intermediary software and that’s the gap we stepped in to fill.

Did you have to invest a lot of time in educating the doctors on how to use the software or what potential benefits they would get? 

Honestly, the first few we didn’t have to, because they proactively told us that they need it, so it was more about convincing ourselves to quote for the software. All the doctors who came to us already had the problem, so they were contacting us to build the software, rather than us convincing them about buying it. But after the first few, we had to really sell the proposition to the other doctor’s.

So what’s the revenue model, you charge the doctors to use this or the patients, how does it work?

No, we charge the doctors. We give the software to the doctors and doctors pay us on an annual basis. Now what does the software do for the doctors, it helps them with four main things, one- it helps the doctors in scheduling, so all the appointments, reminders to the patients about their appointments are done through our software, it basically ensures that without any manual information the patients are reminded about their appointments and the patients visit the clinic on schedule. So the dropout rate because of being misinformed or not informed comes down drastically.

The second thing is EMR or Electronic Medical Records, just like my father’s report or my eye prescription. We allow the doctors to maintain all the digital records on an account of the patients. Now this information can be inscribed, a prescription, printout, and every type of medical information that can be stored about the patient.

The third thing is billing, so doctors who are doing billing manually or on MS Word or any other intermediary software can now do it on ours.

Finally we have built a functionality to generate reports; reports allow the doctors to keep the history of patients. So for example the doctor will come to know how many new patients they have seen in a month, such data could never be accessed earlier by a and we allow the doctors to see how many patients they have examined, the money they have paid, how much has been expensed, what is the profit for the month.

Shashank, you have a young team. I looked at that photograph on your website; they are all youngsters, average age, probably 25 or so, how do you keep them motivated and charged up to kind of support you in whatever you are doing? 

One of the thing that has worked for us is that even though I started the company, we ensure that everybody feels that this company is theirs by making sure that some part of the responsibility is completely given to them. Take our website for instance, the person who designed it used grey as the background color and frankly I hated the color but it was his design, it was his work, so even though I did not like it I allowed it to continue.

I make sure that each and every creator has ownership, and that’s what keeps them motivated. The other thing we did is to add experienced people to the mix and now we have about 30 people in the company who provide the experience to the team members who are inexperienced so that they can learn a different dimension of the corporate world. This keeps everyone going.

Finally, the idea that we set out with never changed. Whatever we embarked on from day  one continues to stay. This is a very good thing that binds us all together. 

How do you really take care of balancing the expectations of various stakeholders – investors, customers and your own employees… 

That is a great question and obviously it is a tough ask, but I have this pyramid of priorities that I have created in my life. Whenever a major decision is taken, I have a mental image of the pyramid. At the top of the pyramid is the company vision. The second block pertains to the needs of the customer; the third relates to my employees, fourth is the investor and fifth is me. So I ensure that any decision that I have to take, it is a combination of these priorities.

So where does this go from here? Are you looking at international market, what is your vision, what is your roadmap for the future? 

Our approach is very clear – we want to enhance the patient’s experience of healthcare. We also want to help doctors to be more effective in doing several things – working in their clinic, treating patients and learning new things among others. So with two fundamental principles of helping the patient and helping the doctor, we believe we can concentrate on healthcare for all of us. Implementing the solution in India certainly is a focus but there is no reason why it cannot be scaled and implemented overseas so we have set up base in Singapore and already gained a customer there.

Posted on

“Envision, Evangelise and Execute”: Connecting with Satyajeet from Cleartrip #PNHangout

We recently had a chance to catch up with Satyajeet Singh – head of Cleartrip’s mobile solutions, on Cleartrip and his take on the role of a product manager in Cleartrip, here’s what we learnt:

Cleartrip has been an early adopter of m-commerce in India. How have you been involved in taking Cleatrip’s mobile offerings from a MVP, to the product that it is today. How did you ensure it was scaled the right way and it grew? 

A) Cleartrip launched its mobile site 3 years ago and was by definition,  a minimum viable product: In the first version, users could only book a one-way ticket for one traveller and nothing more.  

When we launched Cleartrip for mobiles, smartphones weren’t as popular as they are now and anything we earned wouldn’t have a large impact on our revenue. So we took small steps to make our mobile offerings market ready. We did not want to overwhelm the user with too many options, and we slowly scaled the product with more features as the market grew. Today we have apps for all major platforms and one of the most comprehensive mobile site, with mobile contributing over 25% of the traffic for us.

My first priority has always been to deliver the very best products we can, for our customers and it is very gratifying to see it getting recognized within the country as well as at international forums. 

You’ve been in product management for over 8 years now, what do you think is the role of a product manager in an organization? 

A) Envision, Evangelize, Execute, are the three key roles a product manager has to perform in any organization.  

Envision

This means having a clear picture of the problem you are trying to solve, the solution and the strategy that will lead you there. It requires deep understanding of target users, the existing solutions and competitors in the market and a compelling case for why your solution will win over the existing alternatives. 

Evangelize

An equally important aspect of my role is evangelizing  your vision to your team. The more you focus on thisthe easier it’ll be to executeAnd once the team is convinced with your vision, you’ll be amazed to see the change it’ll bring to the output.  

Execute

Remember the quote from The Social Network, “If you guys were the inventors of Facebook, you’d have invented Facebook.”

It is one of the most critical aspects of product management and means doing whatever it takes to ensure your product ships. 

How do you organize your week and what are some of the tools you use to manage your work?

I try planning my week ahead by setting broad goals that can be achieved by the end of the week. My weekly goals could include tasks like calls, meetings, interviews, data analysis, and every little thing that I can foresee for that week. Planning for each day  is usually impractical so I set a broad theme for each day and try and stick to it; for example, Marketing Monday’s is when I spend more time understanding impact of marketing campaigns, or Competition Wednesdays where I try to catch up on the competitor’s activities. 

I also dedicate at least one day every two weeks, purely to plan future releases and to do a postmortem on our recent releases. 

Some of the tools we use are, Basecamp for collaboration, Jira for tracking bugs, Evernote & Wunderlist to organize my work and Excel for everything else 

How do you go about understanding your customers and his/her needs?  

We get a lot of feedback from our users through emails, app reviews, complaints, tweets, Facebook comments and by talking to them directly. But while collecting this feedback, my focus is always  to understand why users want a certain feature(instead of making a bucket list of what they want) or else you’ll end up building ‘faster horses’. 

Analytics is the other very powerful source of understanding and predicting market needs and for fixing critical bugs. 

It’s a mix of the two(feedback and analytics) that gives a good base for prioritizing releases. Making decisions by looking at just one side of the picture can sometimes prove fatal for products.  

Product managers spend much of their time communicating ideas, plans, designs, and tasks to their teams. How do you ensure that it is done effectively?  

You need to champion the three levels of communication between the teams. 

Long term:  By conveying your vision to the team and making sure that they are aware of the problem you are trying to solveis extremely important if you want a self motivated team. Even if they find it repetitive, you need to communicate it often, so that they don’t lose sight of it.

Short term: This includes communicating to all the people who will help in achieving this vision. It is mainly in a form of a product roadmap. You can share a broad yearly plan and a detailed quarterly plan that will enable everyone to plan accordingly. Make sure to keep all the stakeholders as involved/informed. 

Immediate: This would include the day-to-day communication that is required for a smooth functioning of your roadmap. SCRUMs, feedback on designs, prioritizing bugs, discussing & closing blocker issues, reviewing marketing plans, communicating deviations, escalations, all  fall under this category.  

Q) Any tips for aspiring product managers?

Your products can only be as good as your relation with your teams, so invest time in building a long-term relation with them. By spending time with your team you build trust and respect, that will keep them equally excited & help you achieve your goals. 

Editor’s Note: Every member of the product team is important. To succeed, a company must design, build, test and market the product effectively. That said, there is one role that is absolutely crucial to producing a good product, yet it is often the most misunderstood and underutilized of all the roles. This is the role of the product manager. #PNHangout is an ongoing series where we talk to Product Managers from various companies to understand what drives them, the tools they use, the products they work on, how they go about their day and the role they play in defining the products success. 

If you have any feedback or questions that you would like answered in this series feel free to tweet to me: @akashj

Posted on

Don’t try to solve every customer problem by a line of code.

My First playbook roundtable. iSPIRT’s first initiative at Hyderabad, was a 4 hour insightful RoundTable that was  organised by the ProductNation free of cost for the attendees, which most Hyderabadi entrepreneurs gave a miss and are sure to be regretting the missed opportunity and the learning possibility that it offered.

Sridhar Ranganathan, ex-VP of InMobi, a Product Guru and Aneesh Reddy, the CEO of Capillary Technologies, which is in the business of providing mobile-based customer acquisition, tracking, and loyalty business, were the key speakers for the day .The first half of the session was mostly participants- driven where each of us were asked to share our day-to-day stories at work along with our expectations from the workshop.

Below were the most common challenges that emerged from our discussions:

  1. How to validate the need for a product?
  2. How to prioritize from the features wish list?
  3. What is the exact role of a Product Manager to drive successful product deliveries?

Validating the product need

Sridhar began the afternoon session by saying that, “The best way to validate the need for a product was constantly interacting with the customers and understanding their requirements.” He said there are 2 primary things for a product startup to be successful in the long run. One is Speed- wherein it is important for start-ups to be iterating faster as its always better to Fail Fast and recover quickly.

The second is to be data-driven wherein start-ups should be religiously looking and researching in terms of numbers both externally and internally .He recalled a popular quote, “Data is God and code is only a messenger”, which was truly an eye-opener as it made me realize the importance of constantly looking at data and then using that to validate the need of the product.

Aneesh shared a few of his real-life examples on how during their initial days at Capillary Technologies, they had spent over 6 months talking to every store owner be it big or small, to understand their needs and how they literally changed their product idea thrice before conceiving the final version. He also said that listening to customers played a prominent role in shaping the product rather than merely selling. He also spoke of how Capillary mainly stuck to one mantra i.e.- “Locking down on the cheque with the customer even before building a feature for them,” which not only drives a sense of stickiness and commitment with the customer but  also ensures the right customer need is addressed.

Priortizing from the Features Wish list

This is by far the most common challenge faced by all of us today, which Sridhar strongly advocated by highlighting the need for PMs to start questioning  every feature-benefit ratio in order to prevent any feature overload. He also stressed on the need for every PM to evaluate if every feature was designed for the ease of the end user. He added that it is important to add features in a disciplined manner and remove the excessive features ruthlessly. Bottom-line being – “Don’t try to solve every customer problem by a line of code.”

Aneesh also shared on how Capillary builds prototypes and demonstrates them to customers to ensure if the customer’s wish list has been fulfilled or not and that this has helped Capillary to keep the fine balance between what their customers are looking for and how the future of the product would shape up.

Role of a Product Manager (PM)

Sridhar began asking each of us to define what we considered the role of a PM to be and after everyone was done presenting their respective  viewpoints, he mentioned the below as some of the qualities he would expect a PM to possess:

  1. Empathy towards customers – the willingness to engage, understand and appreciate customer needs.
  2. Confidence to have a point of view
  3. Ready to build a product for the future
  4. Culture of experimentation and being data-driven

Personally what I considered the best piece of advice for PMs is, “to be responsible for the Outcome and not the Output”. This actually accelerates the need for PMs to question every effort for a feature request and evaluate what would be its ability to generate revenue.

Overall, it was an immensely insightful session. I would also like to thank Sridhar for taking time out from his busy schedule to enlighten us. Huge thanks to Aneesh for being extremely patient and for responding to all our queries.

I highly appreciate the efforts of Avinash to create such a splendid product management session wherein we not only get a chance to meet/network with product gurus but also help us rethink our working strategies. Last but not the least, I would also like to thank Pramati Technologies for being an excellent host for this Roundtable.

Eagerly looking forward to the follow-up session soon!

Post Contributed by Thulasi, Associate Product Manager at Versant Online Solutions Pvt Ltd and can be reached at thulasi(at)moozup.com

Posted on

“For a product business the product roadmap, customer segmentation and a delightful user experience are extremely crucial.”

Started in 2011 with only three employees, Emportant has grown to serve thousands of users with their cloud based end-to-end HR and Payroll products. Co-Founder and CEO, Emportant, Sandeep Todi says his company is focused to appeal to firms that would identify with its motto, ’Employees are Important’.  In an interview with ProductNation, he says his biggest learning is you must always take good care of your customers even as you keep expanding.

How would you describe the shifting paradigm from Outsourcing software to Software as a Service?

Software as a Service (SaaS) allows you to try business class software with ease and without being tied down with painful and expensive procurement and deployment cycles. With no upfront investment, it’s easy to try and buy SaaS products. In that sense, a SaaS network of products mimic the behavior of a ‘technology grid’ that you can tap into. In contrast, building custom software is like installing a captive power generation unit at prohibitive cost that is hardly justified when the grid is at your doorstep.

Companies have also realized that SaaS is not just amortizing costs over several years, but a new way of thinking. You are not selling a box, rather a product that’s constantly on the move. SaaS products see anything around 4-12 releases a year, are built on rapid release cycles. Moreover, customer feedback is acknowledged and incorporated in these rapid release iterations, something which is impossible in outsourced software or licensed software. The customer is therefore always on the latest release and does not suffer from “version fatigue”. Businesses are realizing this by adopting SaaS products with very little risk, tasting success and then quickly going on to embrace this new pedagogy.

In what way does this new model benefit users in terms of effectiveness, cost and support?

This SaaS apps-grid or ecosystem of apps that can co-exist with each other, is becoming more powerful by the day. No outsourced software is able to deliver this as elegantly and as cost effectively as SaaS product delivered over the cloud.

SaaS software is able to deliver benefits rapidly through new releases and eliminates risk of obsolescence. FUD (fear, uncertainty and doubt) has been used by traditional software vendors, scaring users about impending obsolescence. Having left with little choice, customers had to regardless opt for expensive upgrades and consulting efforts. A transparent SaaS business always keeps users on the latest version and ensures that this version works 100% with all customer environments. This dramatically lowers the cost of maintaining the product because you are no longer dealing with different versions that must be supported for different customers.

Tell us the story about your recently launched web based HRMS and Payroll software, Emportant? How did it happen?

We are in the HR software business for nine years now. Having sold our product PowerApps to several mid-to-large enterprises, we delivered mission critical and high performance HR/Payroll software to customers like Bank of Baroda, Ford, TI Group, ITC, L&T, GTL etc. In 2009, we wanted to adopt cloud computing in a big way and struggled for two years. It was then that we decided to carve out a separate company and a separate product for the cloud – this was the genesis of the birth of Emportant in 2011.

In creating Emportant we initially feared it would cannibalize our own product PowerApps. Thankfully, that did not happen and now both products have a good market presence of their own in two different customer segments.

Emportant.com drives every HR process with the Employee at the center. Every HR / Manager / Employee interaction can be initiated by the Employee and is available on a self-serve platform.

How easy or difficult is it to market a software product in India?

The going was pretty tough in 2011 as cloud was not very well accepted back then. Now it’s different, as CIOs are less wary about the cloud and more concerned about the stability of the vendor, maturity of the cloud product, etc.

Custom software is still viewed as a viable alternative primarily due to the inexpensive cost of hiring programmers. Moreover for a product sold to mid-market and large businesses, you have to traditionally sell one-to-one, engage in multiple meetings and convince customers about the solution fitment without landing into the trap of customization.

What are the factors that make a successful software product and the challenges faced in taking it to the market?

For a product business the product roadmap, customer segmentation and a delightful user experience are extremely crucial.

We have focused on how HR can be employee friendly and have a focus on achieving business results using software tools. The product’s benefits must be easily understood and should quickly demonstrate value. We have successfully kept bringing original thought and real customer feedback into our product, coming out with unique and uncomplicated ways of solving business problems.

Emportant drives HR administration in real time and moves away from the concept of HR software being only a system of record. This model of ours has led to a success rate of > 80% in converting prospects to customers.

We are now looking at stepping up our efforts on social media and on overseas customer acquisitions. Establishing credibility amongst large customers continues to pose interesting challenges and working with business partners means we have to convince them about long term value vs upfront margins.

What is the future of software products vis-a-vis services?

Software products and services will always have their own separate customer segments. I don’t think software products can solve every business problem out there and services have an important part to play. Customers are beginning to realize that service consumption burdens them with unreasonable costs of operation and in an increasingly competitive world they would rather adopt a product if one exists which can meet their requirements. The benefits of products to the customer in terms of cost, sustainability and continuous improvement are already well established.

Look at Dropbox’s recently announced Datastore API. They have just commoditized the offline storage market for independent app makers. In fact, storage is now being turned from a service into a product as will be any service which can be wrapped into a standardized and repeatable delivery.

What learning would you like to share with other product companies?

Every launch of a new version is a learning experience for us. We are faced with the challenge of what to build in the next version, how does it affect pricing and how does it affect our current customers. What we’ve learnt is that you must always take good care of your current customers even as you keep expanding. To ensure this, we reward existing customers with new features for free whenever we release new versions and keep them protected on price changes perpetually.

What role do you foresee ProductNation to play in nurturing the growth of software products?

The biggest obstacle to exponential growth of Indian products is the lack of access to experts in marketing, product growth and cutting edge technology. Too many companies face mortality because of an idea or execution gone wrong.

ProductNation will hopefully help overcome these hurdles quickly and open up the opportunity for Indian products to be recognized globally.

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

How to think about a product startup progress ?

One of the most difficult things in a product startup is to know when has progress happened and if it is in the right track. This is an even more difficult problem for first time product entrepreneurs. Not to say that it easy for a second time entrepreneur but in that case experience intuitively guides.

Most prevalent thinking is to go from idea to a product build phase leading to a launch in alpha & beta followed by several product releases. Sales & marketing gets somewhat sprinkled on top of this mostly spread after the beta release.

Another way to think about this that I have found very useful is the following.

When the anatomy of an idea is examined it leads to revealing of problem and solution hypothesis inside it.

Problem/Solution Fit

The first stage or milestone therefore lends itself to a problem/solution fit. This is the stage when product idea under question has established that it addresses a large pain point and demonstrated a solution that works well for the problem faced for a specific set of users/customers.   For a B2C company this occurs when a few 1000 of users exists and some amount of recurrence or stickiness exist. In case of B2B or SMB product 1- 5 paid or evangelist customers.

User/Experience Fit 

Subsequently this milestone involves having identified the right architecture/flow, copywriting that connects & forms right positioning in the mind, visual and graphic design to create an element of identity for perception and recall.  Essentially providing an experience to the identified user/customers that truly delights and  helps improve acquisition and create retention.

Product/Market Fit

Product/Market Fit is a term that was coined by Marc Andreessen. It means being in a market with a product that can satisfy the market. It is the stage where the product is used or adopted repeatedly by a sizable number of users/customers

Sean Ellis further refined the definition to say that in a survey with customers they are told that product that they are have been exposed would be discontinued and if at least 40% of customers will revolt at that the thought.

In B2B/SMB it is few 50-100 customers and beyond, In B2C it is at least 200,000 users with a good repeat usage could be roughly called to.

Business Model/Scale Fit

It is the growth stage where the right business model for growing at scale is identified at which truly phenomenal growth happens.

Up until the Product/Market fit it is phase of learning and discovery and several iterations & pivots can and do happen.  While this happens it is also important to keep in mind another stage though not related to the product but an important one.

Founder/Problem Fit

Sometimes founder starts with a big vision about the product idea however having to identify a problem that is truly worth solving can be highly iterative process and can look very different from what was originally envisioned. It is important for the founder to re-establish that the revised version is indeed something that continues to motivate to build.  This stage ideally should be post problem/solution fit and before user/experience fit.

This model is not an original one or not even the only model of thinking about stages of a product startup but it helps frame answers for many things.

    • Each successive stage marks reduction of uncertainty and better modeling of risks in product success journey.
    • Visits, Page Views, number of downloads are not good enough for product/market fit. It may be necessary but not sufficient.
    • Product/market fit success is not equal to business success. In my previous startup I built a mobile app (turn phone into webcam) with over 1.5 million downloads and very high daily active usage and along with an excellent NPS. Product was super success but with no business model ( in the pre iOS era  of no app store or mobile ads) the business did not succeed.
    • Early business traction is not equal to product success (not even problem/solution fit). Ex: Several of the Indian e-commerce companies.
    • Job of an accelerator is to help take companies beyond Problem/Solution fit. If the market structure allows smaller cycle feedback loop then it should even achieve User/Experience fit by the time startups graduate from these accelerators. Unfortunately many view accelerator as a way to get funded forward.
    • In India most of the product startups are stuck at just before reaching problem/solution fit and also just before product/market fit.

What are the mental map of your product startup progress ?

Posted on

Don’t Build Something Unless Someone Is Willing To Pay For It & Asks For It Twice!

Notes from the  Product Management Roundtable In Bangalore. Having attended the first ever iSPIRT Roundtable on Product Positioning in Bangalore and closely followed the second one held in Delhi, I was eagerly looking forward to the Round table in Bangalore on Product Management by Sridhar Ranganathan. Sridhar is a senior Product Management professional having spent considerable time in product management roles in companies like Zoho, Yahoo! and InMobi.

The 12 startups that participated in the round table consisted of a healthy mix of companies across various stages wrt their Product organization – some already had a PM function set up, some were scaling fast and were looking for ways to make their first PM hire and some where the CEOs or the founders were themselves donning the hat of a Product Manager.

The session started with a round of introductions and an open discussion around various aspects of Product Management – need for Product Management, hiring of Product Managers and setting up the team, prioritization, building an MVP etc. which set the right tone for the rest of Roundtable.


Sridhar shared his experiences of being a Product Manager and a Product Management leader in his previous roles. His experiences at Zoho were particularly of a lot of interest to the participants, as Sridhar was at Zoho during the period it transitioned from a company making Network Management Systems to the Saas giant it is today. He mentioned how the founders had a strong faith in setting up a Product Management function and empowering the Product Managers to lead the product efforts. He said it was like changing gears from moving in 4 big ships to 11 speedboats – with a Product Manager navigating each speedboat (a product). One insight Sridhar shared stood out, that the founding team needs to strongly believe that there’s a need for Product Manager(s) in the company and remain fully invested in the idea. Otherwise, there are very few chances of a Product Manager making a meaningful contribution and succeeding in their role.

Here  are some key insights from the discussions at the Round Table:

Product Management is a highly cerebral activity

The importance of setting a conducive environment for the Product Management setup was stressed upon heavily by Sridhar.  It is imperative that between the Product Manager and the immediate Product team (engineers, designers, QA), there be a very high amount of trust. The decisions of the Product Manager will directly impact the work, and subsequently the performance of the engineering team. Similarly, the Product Managers needs to believe that his engineers are capable and are able to solve the challenges he poses to them.  Laying the right foundation and building trust among the team is absolutely essential for the Product Management team to contribute significantly towards the company’s goals.

Framework to Solve Customers’ Pain Points

The discussion then moved towards prioritization of tasks, catering to customer requests for feature additions and customizations. Sridhar presented a very interesting framework which is quite handy to place customers’ pain points in the right context and solve them appropriately.

 

Depending on the target group size is and the complexity of the pain point, one can address the pain points in different ways

  • Education: Can you provide simple walkthroughs of the product through screencasts or tooltips, put down a set of FAQs that customers can refer to and get the help they’re looking for?

  • Process: Can you tell customers on how to do something? As an example, creating a 1-page document on how to apply for a passport and redirecting customers to that section would be a way of setting up the process.

  • Procedure: Taking the above example itself, if you actually build a feature to help customers apply for a passport, it would be creating a procedure to solve a pain point.

  • Solution: Any customizations/hacks over an existing feature/flow would fall under this.

  • Product: Enabling the customers to do something completely through the product itself. E.g. Employee payroll processing.

Building an MVP

How much time should one spend in building the MVP? One of the keenly debated questions was on the amount of time to spend to build an MVP. While there were multiple inputs based on the nature of the product and the market each of the companies was targeting.  However, Sridhar mentioned that one should invest enough time so as to avoid having to pivot at a later stage.

Is your product a ‘painkiller’ or a ‘vitamin’? It is important to understand this very well beforehand and pitch the product in the right manner to your first set of customers. You may be overselling if you’re trying to pitch a vitamin disguised as a painkiller and grossly underselling if it is the other way round!

What features get built into the MVP? Don’t build the product or a feature just because someone says it’s a good idea or if your prototypes ‘look good’. You need to validate that the customer is indeed willing to pay for the product. It’s even better if they ask for something repeatedly, which indicates that they have a pain point and they are willing to use the product/feature.

Taking the MVP to the market. Choose customers who can challenge you and make you think harder. The first 5% of the customers give 85% of the important feedback and the interest tapers off as you get the next set of customers. It is important to keep validating your view of the market and be ahead of the curve. You may have built something that was relevant at a previous time or maybe talking to a customer set that’s no longer representative of the larger market out there.

When to get a PM and what should the PM spend time one?

Sridhar suggested that whether or not there’s a formal designation assigned, there should be a Product Owner from Day 1, which is invariably one of the founders. Over time, it will be good if one can identify a good Product person from among the early engineers and have a Product person for a group of 7-8 engineers. The Product Manager should ideally be able to do 70% of everything! For the effective use of a Product Manager’s time, a helpful rule of thumb is that he spends 50% of his time planning for the future, 30% of the time on current initiatives and 20% of the time on firefighting.

Data, Intuition & Processes

How much does one trust data and how much does one rely on intuition to make decisions?

One of the participants remarked – “If you torture data long enough, you’ll get what you want”. It was general view shared among the participants and endorsed by Sridhar that data is good for discussions and not decisions. There’s a strong element of intuition and market understanding that go into making decisions and there should be ample scope for that.  Finally, it’s the Product Manager’s call on the direction of the product and he needs to be able to take views from multiple perspectives. Data alone being the decision criterion may not be the best way to go about it.

What about processes? Do they kill creativity or actually help in better productivity and accountability?

A quick poll on what the participants thought about process threw up some interesting responses. The hardcore engineers found process to be a bit of hindrance. However when they put on the founder/senior management hat, they found that there needs to be some way to maintain accountability and provide better visibility to a larger group as a company grows. As one of the participants rightly said, process is ‘doing what you say and saying what you do’.

Sridhar cautioned against having too many processes (don’t put policeman unless there’s a lot of traffic) ot of traffic), he also shared some interesting ways of bringing in process. Rather than enforcing process, can the employees themselves be stakeholders in implementing process and are ihe also shared some interesting ways of bringing in process. Rather than enforcing process, can the employees themselves be stakeholders in implementing process and are incentivized for taking an active part in the process and evangelizing it?

Each of the participants took away some key actionables which they’d go back and try out at their respective companies. They’d also stay in touch to share their learnings and experiences to help one another build a strong product management function. After all, we’re working towards transforming a nation with products!

Posted on

To open source or not….

Ashok was perturbed. In Jan 2006, an eastern European company had taken his source code, made minor changes and started selling it under an alternate brand name at a reduced price. Ashok’s company Chartengo was a pioneer in Adobe Flash based charting software that helped users create charts for data visualization. Its charts were perceptibly superior to any available on the market. The company had five employees and revenues of $500,000 in 2006. It used to offer source code with its USD 99 developer version of the product. A growing business like Chartengo was sandwiched between free libraries on the Internet and large data visualization vendors (revenues > $100 million) on the other. In between it also had to content with few hundreds of competitors. The possibility of a vendor infringing on Chartengo IP in some distant corner of the globe was high.

Chartengo did not have a legal team so they contacted a firm that specialised in copyright infringements. The firm quoted $250,000 to file a suit but there would be additional fees for court appearances. besides the unaffordable legal fees, Ashok was apprehensive about the stance an eastern European court would take in this matter. He decided to forego the legal route. He talked to development team and few experts outside. A surprise suggestion with overwhelming majority was – make your product code open source. They said open source code will make it difficult for infringers to compete. Why should customers pay for a code that is open source from the original vendor? Ashok’s team of developers was thrilled with the idea of open sourcing their code. It would accelerate innovation and save them time developing everything themselves. They felt perhaps the customers would also be happy. They could also see an opportunity for higher revenues. The open source would probably draw more customers, especially those who were sceptic of dealing with a small company like Chartengo.

Ashok had so far found it the best strategy to protect its intellectual property. He believed innovation would only happen if it could be exploited for exclusive financial benefits of the innovator. How could he even think of handing over his crown jewels to the infringers in the marketplace? The thought of handing over his IP to these hackers and letting them enter their random untested code into it thus contaminating its pure quality was appalling to Ashok. He clearly saw his competitive advantage evaporating with opening his source code. Yet, at that time, open source was rising like a tsunami? Apart from individuals hacking into your code, well-funded companies were also doing so. There was passion about open source. Even customers were enamoured by open source culture. It was turning into a religion.

The question is – what should Ashok should do?

Posted on

Notes on Product Management – insights from Slideshare / MMT / ex-Google PM

Avinash Raghava, who is doing a wonderful job of getting product start-ups together all over India, organized a product management roundtable with the help of Aneesh Reddy(CEO, Capillary). They invited Amit Ranjan (Cofounder, Slideshare – acquired by LinkedIn) and Amit Somani (Chief Product Officer, Makemytrip, ex-Google) to share their insights with a small set of entrepreneurs.

Credit for all the good stuff goes to Amit Ranjan, Amit Somani and Aneesh Reddy. Notes are rough. If anything is unclear, feel free to comment.

Here are some quick notes/thoughts from the event:

Who would make a good product manager?
Someone who can do 70% of everything (coding, design, listening to users etc.)

Best way to find a product manager in India is to find someone who did a startup but failed – he/she is likely to know all the various aspects that go into managing a product.

Someone who can lead by influence and manage to juggle all the balls in the air. Should be someone who can say NO.

It’s a very tough position to hire for – you need to have patience – you might go wrong the first few times. Once hired, give them around 5-6 months to get the hang of the whole thing.

What does a product manager do? What is his role about?
A good product manager would understand the requirements from various constituents and write a detailed specification, plan for bugs, testing, urgent requests and then create a product roadmap/deadlines.

A product manager has to identify and write down what metrics will move once the product is launched (e.g launching the mobile app will increase our repeat orders by 9%) – in some cases it is just to ensure that people work on things that matter but overtime it also brings more accountability.

User specs should have – what all do you need, who will use it and why – need to be elaborate it before you give it – need a hypothesis that will it move an X metric. Read thetwo page spec document that Joel Spolsky wrote for a fictional website What time is it? It should also have non-goals – what the product does NOT try to do.

Engineers tend to underestimate the time it’ll take – product manager needs to be able to correctly estimate how long something should take. And you will get better at it with time.

Use the 1/1/1 rule – sit with the engineering team and plan what needs to be accomplished in 1 week, 1 month and 1 six-month period.

People want to see the product roadmap – it is important for the CEO / Product Manager to communicate this to their team mates since a lot of people feel uncomfortable if they don’t have a clear idea of where the product is headed. (Amit Ranjan mentioned that people may even leave if they feel that the founding team does not have a clear vision – but the nature of start-ups is such that it is bound to happen that the product roadmap keeps evolving)

You need to hire coders who have a design sense (that eliminates 70% of work later).

Role of special data or analytics person has become very important (Amit Ranjan said that he could see that products of the future will be decided and influenced by data scientists). It is very important to get such a person on board early. Someone who has crunched SQL and nosql logs etc and can find trends and look up aberrations. Read up on Hal Varian and DJ Patil to understand more about this.

Difference between customer requirements and product requirements – customer requirement only becomes product requirement when more than 3 people require it (it’s a rule of thumb) – (People shared various tricks they use to ensure that the customer requirement is serious – “just wait for a few days and see if they come back with the same request”, “ask them to email it and not take feedback over the phone” etc. – these are situations where there is too much feedback coming your way. In most cases, it is best to make it as easy as possible for people to give you feedback).

Keep product engineering teams small – Amit Somani mentioned Jeff Bezos Two Pizza rule i.e. if the team cannot be fed by two pizzas alone, it is too big. Read more here.

Try to do daily scrum – gives everyone a sense of what everyone else is doing and ensures that people are making progress

Everything is a 6 page document – another Jeff Bezos funda for getting clarity. So a specification or a product request could be a 6 page long form document which ensures that the person achieves clarity before building anything.

You need to benchmark your product against other products especially in enterprise. When starting a product from scratch this can be a really useful exercise.

Amit Somani suggested a mental trick – before building a product, write a one page press release for the product that comes out upon product launch – what will this press release have? What the key features? The target audience etc. This PR drafting exercise could help you decide what to build, what is critical, and for which audience.

Don’t ignore email as a channel for activation and returning visitors

Product activation – Use banners on your own website – do get them to take action – on landing page – on other parts of the website

Track at your mobile traffic – people at the roundtable reported some crazy growth numbers for mobile internet usage – huge sites are now getting 20% to 60% of their traffic on mobile. Mobile traffic is split 50%-50% on mobile browser (including WAP) and mobile apps. This was a big eye opener for many people.

Tools people recommended

Use Trello (a Joel Spolsky product) to manage your product

Use Zapier business tool to connect various sources of product input (e.g. taking Zendesk tickets and automatically creating Github issues)

Use Clicktale or Inspectlet to record user sessions

Use Morae for recording users’ reactions when they are using your product ((Amit Somani mentioned how they put a live usage recording on a LCD screen in the technology room so that engineers could understand how their products were being used – it lead to a lot “can’t he just click on the button! Why is he scrolling up and down!”). One way to get users for such recordings is to ask interview candidates who come to your office to use your product and see their reactions.

Use a call-outs software when introducing new product features (like Cleartrip / WordPress / Facebook do).

Concluding notes
This was one of the most gyan-heavy sessions that I’ve attended. It was useful to hear things from people who had been there done that. Aneesh (even though he is based out of Bangalore) had taken the lead to do this with Avinash and our hope is that the group meets every 6 weeks to keep the conversation going. We’ll keep you posted.

Feel free to email me at ankur AT Akosha dot com if you’d like me to give more details to you.

On a related note, there was some basic debate about what a “product” is. We didn’t get into it at length because everyone in the room intuitively understood what a “product” was. However, we had internally debated about it – if you are interested, do read –Understanding Product v. Service [ThinkLabs Notes 1].

Reblogged from the Akosha Blog by Ankur Singla

Posted on

How to debug a product startup idea ?

You may find it useful to read the previous post on importance of ambiguity tolerance and questioning for an engineer transitioning to a product guy before reading this post.

When I was first tasked with writing new features for an existing product that contained thousands of lines of code I earnestly started reading through the documentation & code to understand how it is structured and to figure out the APIs to use. My then engineering mentor said to me

” Reading through the documentation & code you will spend days or even weeks forming mental model which you will learn may not be accurate as you implement your code later on, leading to a lot of wastage of time and redoing.  Instead setup your environment, load the code inside a debugger, put a breakpoint and run it through. If there are specific areas you want to learn  then ‘step in’ to that function. This way you will learn about it faster, more accurately and spend less time redoing “

I found this advice to be a great insight and I think it extends in many places.

As a product startup one always start with an idea and then forms mental models around that (business plan or business case studies) and then build things based on these models to later realize they were not accurate thus wasting a lot of time. In the harsh world of startups you don’t get another chance to re-write.

You have to know very early if your idea will work before you can commit a lot resources on it. Things that determine if your idea works are some of the following –

Will it be adopted by users,

Will it talked about to friends,

Will it paid for by someone,

Or even celebrated & craved.

Essentially will it create the impact for you and the world that you dream it will.

MVP – your Idea Debugger

To know if your idea will work you should run it through a debugger that can tell you that the logic of idea will lead to its intended impact.

Enter the Minimum Viable Product (MVP), a term first coined by Frank Robinson and further popularized by Eric Ries.  Today it is a term that is quite loosely & liberally used and at times even abused.  MVP is a misnomer in the sense it is not the stripped version of the product but it is really a tool about learning & risk reduction around customer & market.  It is employed to uncover critical learning of your idea.  MVP is best thought of as the debugger of your product idea.

Before we start getting into the details of an MVP, let’s examine the anatomy of an idea first

Idea Anatomy

An Idea consists of the following elements

Anatomy of an Idea
Anatomy of an Idea

Vision – A new state of the world that will be in place if the idea becomes successful.

Problem – A friction that is coming in the way of job that a beneficiary is trying to get done

Solution – A proposed alternative for removing the friction

Beneficiary (also called as Customer* or a User**) – Someone who is going to benefit from the idea

* Customer is one who writes the cheque for the service consumed.
**User is someone who uses the product or service

 

Example:

Let us take an example to illustrate. Suppose you came up with an idea for creating a mobile SariApp that shows how to drape a sari.  It could be dissected the following way.

SariApp Vision:  More women in the world  in touch with their Indian traditions (or traditional Indian dressing)

SariApp Problem:  Would like to wear a sari for attending an Indian function but have no past experience or knowledge of draping a sari.

SariApp Solution:  A screen by screen illustration of each step of sari draping.

SariApp Beneficiaries (customer):  Women who have been fascinated by this Indian dress or those who who grew up outside of India never bought a sari before.

Once you do this you realize that problem, solution & beneficiaries are all at best guesses or assumptions that you make.  The task of debugging your idea thus becomes one of converting each of these guesses into verifiable facts that either proves or disproves them.

How MVP clarifies Idea logic

After you list down the things that are big unknowns in your idea you build something minimal (your MVP) to question it. The interesting thing about the MVP is that you have to build one for every idea, the same debugger can’t be used for every idea and the same learning does not apply everywhere. You could design an MVP to test or uncover learning one element or combination of elements (about just problem or combination of problem/solution/customer segment in the idea).

An example of an MVP for the above SariApp could be a simple landing page that articulates clearly the problem statement, the solution and call to action (such as leaving an email address to get contacted when solution becomes ready). Responses from traffic directed to the landing page  will  help learn about the merit of the problem/solution. If there are high number of clicks on your landing page but very few clicks on call to action a most likely interpretation of that could be those who visited care about the problem but not the solution. If the visits itself was very few then it is most likely they don’t care about the problem itself as you have stated it and so on and so forth.

Few things to keep in mind

The fidelity of the MVP is very important aspect to note which describes the minimum-ness of the MVP and plays a key role (see diagram) on the learning and how fast you get it. You have to start with testing the value proposition (a concise statement of problem & solution together) of the idea and increase the fidelity to learn more.
Fidelity of an MVP
Fidelity of an MVP denotes the minimum-ness of the MVP

 In most cases MVP mostly tells what does not work rather than what works or even why it works. One has to iterate over changing the MVP and increasing the fidelity of it.

So what are the debuggers (MVP) you have built for your idea?

In the next post we will look at “Four critical stages of Product Startup Fitness” 

Posted on

“Great Designers Steal”

Picasso Cubism

Picasso is purported to have remarked, “good artists borrow, but great artists steal.” He probably did not mean it in a literal sense. He wanted to inspire us from great works of arts and re-interpret or re-imagine them in a different way. Here are some references that have inspired us to become better designers.

 

Balsamiq Screenshot

 

 

 

 

 

 

1. Balsamiq: Its simple sketchy interface evokes a sense of nostalgia of our playing with crayons as children. The clients don’t get distracted by little details allowing us to focus on important things such as navigation, content prioritization, quantity of content, and what a screen does. You should definitely use this to visualize and share your vision before writing a single line of code. This is also a great tool to communicate user stories within the agile framework.

PatternTap Screenshot

 

 

 

 

 

 

2. Pattern Tap: Its a collection of crowd-sourced design inspirations for all page types and devices. The designs are categorized by facets, so search for “login” to be wowed by how a simple screen can be so beautiful. 

TheNounProject Screenshot

 

 

 

 

 

 

3. The Noun Project: “The mission of The Noun Project is to collect, organize and add to the highly recognizable symbols that form the world’s visual language so they can be shared in a fun and meaningful way.” The symbols are free and delightful. You have see them to believe.

Smashing Magazine Screenshot

 

 

 

 

 

 

4. Smashing Magazine: An online magazine for designers and front end developers, to stay current with the ever evolving tools and techniques. It also has a great compilation of books and ebooks that could be references on your next project.

365psd Screenshot

 

 

 

 

 

 

5. 365psd: 365 psd, needless to say, means one high quality psd file a day. A great resource for free UI kits, page templates, and icons to get you started or help get over the creative block. And do sign up for a freebie everyday.

Google Web Fonts Screenshot

 

 

 

 

 

 

6. Google Web Fonts: Are you still married to times, arial, and helvetica? Here are hundreds of open source free fonts to help design great looking yet highly readable sites.  Don’t forget to look at the “pairings” feature. It recommends best complementary font pairs to add that extra zing to the design.

So go forth and steal, and please keep adding to this list.