Posted on

Zoho, Cloud, Sridhar Vembu

Those who know me well have heard a lot of stories about my experience at Zoho when they transitioned from AdventNet to Zoho. I worked there between 2001-2004 when it was quite a new thing in the indian product ecosystem to talk of Product Management etc. During that period, the company went through a very significant phase of transformation which I was fortunate to be part of, see & learn from close quarters. Today, Zoho was named 4th best Cloud company to work for – makes many of us very proud.

The first thing that struck me was Sridhar’s focus on leveraging data. It went to a point where we realised that inefficient code can put paid to aspirations of leveraging data. And he rethought the data model for our suite of products ground up. The larger ambition was “Deliver software as service, not as installable“. This was in 2003! Back then, the company had about 5 big platform products (SNMP, WebNMS etc). Rethinking the data model, writing and enforcing code that didn’t obfuscate the database (most code was in Java, so it was easy enough to write inefficient code) were tough but important changes he brought about.

Sridhar cared a lot about how teams were organized – large teams are an inherently inefficient lot! Sridhar had the view that teams should be less than 7 people, cross-functional. The reward for growing a team beyond 7 was that it will be split :). His view was that since “Software will be delivered as a Service”, the company should transform from 5 big ships to a 1000 speed boats. To do that, each team team had to focus on a specific market, build and ship a unique product. By 2004 when I was leaving for Yahoo!, there were already 18 products underway. Before the end of the last decade, they were doing over a 100 products!! To go from 5 to 100 in just a few years is quite something.

There’s a lot to lay by the founding DNA of a company and what it can accomplish. While building Credibase which I’ve cofounded a few months ago, here are a few lessons I took away that we try to practice:

Data is God

Focus on the User and all else follows

Small teams create great work

Code always goes from Simple to Spaghetti, but never comes back

Posted on

The Ad Business

Saikrishna Chavali posted the following question on my blog post about Data & UX being two ends of the product spectrum:

I’ve got a question: how did you understand the user when you were in the ad business? Did you ever meet real users? In PM theory, one is instructed to empathise with the user by actually “getting out of the office”.

Since it’s quite an important question, I thought I will take a shot at giving it a detailed point of view, and provoke some conversation.

While building the Ad Network at InMobi, we had 3 key stakeholders to take care of and deliver value to:

  1. Advertisers & Agencies – who had ad budgets, setup and ran the campaigns, and looked at reports & analytics to measure ROI of their ad spend
  2. Publishers & Developers – who had lots of traffic from mobile phones – mobile web, apps etc, and wanted to generate revenue by advertising
  3. Users – who were primarily using these mobile web sites and apps to get their work done, or for entertainment.

When Publishers or Developers say

I want to monetize traffic

they’re basically saying

I have users who use my sites and apps, and I want to make money from them, so that I can sustain my business, and grow it

As an ad network, you have business relationships with Advertisers, Agencies, Publishers & Developers. And as product offering, you build user interfaces and APIs for these people to use. So, by definition, you have to have ongoing dialogue with users from these customer segments. I believe products are for users, and have blogged earlier about it.

At the same time, an ad network makes money when the users (consumers) engage with the ads in some applicable manner – Viewing, Clicking, Playing etc. The effectiveness of the network is increased if we can understand the consumers well enough that we deliver the right kind of ad experiences to them in every context. That bodes the question

How do we understand the consumers effectively?

For a large part, we understand consumers from the data generated by them in our system. Ad businesses typically talk of metrics such as requests, impressions, clicks etc. If these metrics represent a user’s intent in some form, here is how they would play out.

  • Ad Requests – “There’s some space in the screen, can you show me an ad that I might like and click on?”
  • Clicks – “This ad seems really cool and helpful for me. I want to see what the product/service it is showing.”
  • Play (a video) – “I am curious about what this video is, and hence going to watch it.”
  • App Download – “I want this app.”

 

Remember, for every advertiser that wants to run a campaign on your network, the campaign will certainly reach a bunch of publishers (say 50 or thereabouts) who each have access to a few million users (say 1 million each). Assuming there’s a user overlap of about 50% (multiple publishers’ sites or apps being seen by a user), that’s an overall reach of 25Million users (50 x 1M x 50%).

Now, how many days or surveys or phone calls or chats will it take for you as the product manager, to be able to talk to 1% of this target user base?

Come to think of it, the Ad is really the “product” of the “Advertiser” that’s targeted at a “User”. On the other hand, the Advertising System / Interface is the product of the Ad Network for the Advertiser. So, in the strictest sense our loyalties should lie and stop with our customers (Advertisers, Publishers etc).

Clearly that’s not good enough, because the effectiveness of any advertising business is based on the consumers engaging with ads being shown by the advertising system. So, we have a clear objective to improve ad effectiveness with the consumers. Here’s how that gets done.

Let’s say there’s a campaign with 1 ad in it. When these campaigns get setup, and the ad starts getting served, pretty soon, the ad servers start computing answers for questions like

1. How many times did this user click an ad that was shown a few times

2. How many times did this ad get clicked when it was shown a few times, across many users

The first question gives you an indication of whether a particular user liked this ad or not.

The second question gives you an indication of the percentage of people that liked this ad, from the overall population of people who saw this ad – CTR for the ad.

With these two metrics you’re able start understanding if specific ads work for specific users or not. You then architect and instrument your systems to iterate on what ads to show a given user, based on the expected effectiveness of the ad for the given user. So, while on one hand you can design your systems for your customers, based on meaningful real world interactions with them, on the other hand you end up being highly data-driven and experiment-driven to design serving systems that deliver some kind of content to millions of users. No wonder folks with data+tech chops are in high demand among tech companies.

What do you think? What other experiences have you had?

Posted on

The evolving roles in product ecosystem

I was catching up with Avinash (@avinashraghava) earlier today and we were chatting about product startups in the country. If you’ve been in this ecosystem, and seen the evolution of product companies, some interesting changes happened over the past few years.

Back in 2001, at AdventNet, the Product Manager role was created, and so was the Usability Engineer role (which were primarily UX Designers). There used to be debates about project managers and product managers and I’ve had a chance to see these debates well into 2007-08.

While interviewing with Yahoo in 2004, the recruiter was not quite sure of what they wanted me to highlight (since i didn’t come from a software programming background) and asked “have you taken any short courses on programming languages, that you can highlight in your resume?”. I had to politely decline modifying the resume – it would’ve also meant not highlighting the UX-related work I’d done while at AdventNet. Guess that was a time when the tech world was still coming to grips with the need for Product Managers in product companies.

Those days, Yahoo had a good bunch of UX Designers, and not enough companies felt the need to have good UX Designers. I was lucky and fortunate to work with some very smart designers while building products such as Yahoo! Maps, Yahoo! Local etc. Those days, there were conversations about 2-pizza teams (at amazon), 3-people teams (PM-UX-Dev at google) and emerging agile teams.

By 2006-07, the ecosystem had recognized they needed product managers and many product companies started looking for pm talent. And they were getting started on hiring User Experience Designers.

When I moved to InMobi in 2008, we built the PM team, the UX team and also realized that the way to build great products was by leveraging the data we had, to generate analytics and insights. Helping the user with understanding of what’s happening in the system with respect to their work/needs was a great way to get the user engaged with the system. This starts initially (at low data scale) with basic reporting tools – tables, charts etc. As the data grows (and boy, does it grow fast!), these tools have to evolve into more sophisticated ones. The decision systems also crunch lots more data to generate their outputs. And who better to help with those than data scientists.

By this time, most companies and the recruiting world were familiar with and looking to hire UX designers.

Getting a lead on understanding data and building newer insights helps Product Managers think about smarter ways to solve user and business problems. It also helps UX Designers to visualize newer ways to portray information as well as overall experience. It’s no surprise that companies are now looking to hire Data Scientists quite early in the game, especially the ones that want to build world class products. The VCs are also paving the way with roles like Data Scientist in Residence.

I did a small experiment last year, looking through the websites of various companies in the data services spectrum (data warehousing / analytics / data consulting etc). I went through their archived websites of 2008-09 and saw that terminology such as “data warehousing”, “data analytics” etc had given way to “Big Data” starting 2010. I think this is an important trend to understand – tech businesses are prolific at creating data. To leverage that, they need a pretty significant set of people who can understand and make sense out of it.

Now that the world’s all mobile + tablet, the new challenge is “user acquisition”. Growth hacking anyone?

Posted on

Everything is an experiment

A few days back, Sameer, Avinash and I chatted about my learnings from doing the Product Nation Playbook Roundtables as part of iSPIRT. If you’re curious what they are, here’s how iSPIRT describes this program.

We convert conversations into playbooks for product entrepreneurs. Product companies need a different mindset than IT services businesses. They need to anticipate customer needs rather than just react to them. They need to brand themselves in very different ways and create IP that will disrupt the marketplace. They need deep technologists rather than fungible engineers. And so on. pn.ispirt.in will be the platform for enabling crucial conversations around these issues amongst practitioners. It will use an evidence based methodology to shine light on successful playbooks.

From iSpirt website.

I believe building products is a continuous and highly impactful experiment that one can do. More so in today’s digital day and age. Here’s a short video put together by Sameer that captures my thoughts.

Sridhar Ranganathan(CrediBase) sharing his views on “Building a Product is Experiment” from ProductNation on Vimeo.

The key aspect of every experiment is that there’s definitely an OUTCOME! Whether that is good or bad, is something left to the hypothesis one frames, before the experiment.

Meanwhile, a bunch of folks who’re very interested in seeing the product ecosystem evolve in India, have come together to create #PNCamp, a 2-Day Boot Camp for product entrepreneurs. You can learn more about it here, and if you’re a product entrepreneur, I’ll strongly recommend getting an invite for this – you’ll learn a bunch from it. Even this is an experiment, to learn from how to evolve the ecosystem. Do you agree with me? Share your thoughts in the comments section.

Posted on

The importance of organisation architecture

We are used to talking a lot about Organisation Structure in prevailing literature. I believe Organisation Architecture is more fundamental and instrumental in taking the company to the distances they desire. Organisation Structure, to me, is a subset or a component of the Organisation Architecture.

So what do I think of as the Organisation Architecture?

The Organisation Architecture is one that encapsulates the vision of the company, the direction in which the leadership of the company wants to proceed, and the culture that they want to inculcate such that they would get there.

One of the companies I have known said it thus, “We want to go from 4 big ships to a 1000 speed boats (each being a point product from the platform products they were known for), achieved through the means of small, self-contained teams that identified market opportunities, built and shipped the products, and generated business from those”.

While this may read as yet another vision/mission statement, what was implicit in this statement was that they laid out the direction and way of how they will execute it. In essence, it was an architecture on top of which you could have specific manifestations of “applications” that would work harmoniously by themselves and among themselves.

Such an organisation’s architecture gives great latitude for the leadership team to execute on specific initiatives as they identify market opportunities. It gives the company agility to tackle opportune situations and be ready to capitalise on serendipity.

When you look around, every company starts off wanting to be “something”, pivots along the way, and ends up striking pay dirt in another application, then scales or lets go of the opportunity. At all these inflection points, the company needs a fabric of people and mindset that supports a new direction or a change in direction. The organisation architecture enables one to do that.

What do you think?

Posted on

Data and User Experience: Two ends of the spectrum

Every product that you build has to be used by people.

This is irrespective of “who may pay for the product“. This is an often brought up topic of “User vs Customer“. And if the product is used only by machines and not by real people, then it’s perhaps best to call it “technology”.

As far as technology products are concerned, a significant factor of differentiation they claim and deliver on is by leveraging data about usage and user behavior. And in a product team, the cycle goes this way:

  • Product Manager thinks up the product (you can assume that in all these steps, others also contribute meaningfully, as product creation is both an intensely cerebral and collaborative exercise)
  • Designer helps visualize the user experience
  • Engineers code it and get it ready for prime time

The plot:

1. Roll out the current version of your product
2. Get users to use your product, engage with it and contribute inputs (read Data)
3. Collect usage and behavior data, analyze it and generate ideas for the future features
4. Design & develop the new features
5. Start from Step 1 again

If you notice, in this iterative and cyclical process, the two constants are Design new features (UX) and Collect more data. While this cycle goes on, imagine the various changes that happen to your company:

• People added/removed
• Infrastructure modified (change offices/locations etc)
• Technologies changed/added
• Investors changed/added
• Markets discovered/validated
• Pivots created/executed/dropped
• And the list can continue

But the core 2 tasks remain: Design UX for your user, Collect Data from your user, both of them aimed to improve their value proposition. This prompts me to call Data & UX as the two ends of the spectrum of building a tech company. It’s very interesting to note that if Data connotes Scale, UX connotes Empathy. To build a successful company, I imagine that one needs both Scale and Empathy and not just one of them.

What do you think? Let me know in the comments.