Thus Far

I started writing code in grade 7, and in the 8th (in 1988!), had stitched up a desktop app (we called them "projects" back then) that presented visual + text questions - with some level of animated graphics painstakingly coded one motion at a time - to test people's knowledge of road rules and best practices. I saw a very similar - tho of course more advanced - piece of software when I took my driving license test at the DMV in Beaverton, OR.

College was one massive waste of time, except a couple of interesting "projects" we did - from a fundamental growth of knowledge point of view. Sure we picked up a lot of stuff, but didn't really connect to lots of it till much later, as we stumbled upon concept after beautiful concept.

My first job was in operating systems - initially in the command layer and later - nirvana - inside the kernel itself - of a very cutting edge OS for parallel architectures. I learnt new stuff every single day.

The next job came because of a huge jump in salary - and got boring as hell in a few weeks. We were porting massive amounts of code with very little clue to the underlying architectures, designs or even concepts. Personally, that turned out to be a good place because I couldn't bear to stay in front of the screen doing diffs on logs - so automated bits and pieces and improved my scripting skills a lot. Laziness, boredom are indeed drivers of innovation :)

An unexpected switch to an "R&D" group brought much needed activity to the brain - we were trying to solve the problem of base platform developers who needed to fix bugs reported on platforms that the code had been ported on to. Did my first major design work for this - and got to a stage where basic core dumps from one platform could be captured and migrated to the base platform, with context intact, for debugging. Filed a few patents, and this would've had a major impact if it were used for reduced triaging effort and manpower.

The next bit of "R&D" involved mapping pieces of database logic - across constructs and languages - to a common format, looking for opportunity for recommended practices, improvements and optimizations as documented in a huge number of "expert" level books and cross-compiling into an appropriate target language. Awesome work again, and we got to present this and interact with end users for whom this could be potentially very very useful. But, as is the fitrat of R&D projects, that, was that. Of course, with a coupld of more patent applications filed.

Yahoo was a huge opportunity and next step in "impact". I got into the fascinating realm of machine learning, information retrieval and text mining that I had no formal training in, yet took to - more pragmatically than most with formal training - instantly. We did a great job of our project - coming with lots of innovative ideas, techniques and solutions than solved more than just our immediate problem. It was a joyride and even had impact as it got rolled out as a new property for Yahoo India. Of course, where that went then became a question.

Another zoom-out followed as yet another R&D effort where we were trying to model visualize and deal with messages, chats, mails, blogs etc as one : conversations - with social authority and impact used for ranking. This was way before buzz/facebook etc had made an appearance. Good work again. R&D project again :)

Then Ziva happened. An amazing exciting journey that started with ideas, design, implementations, customer interfacing - but took me way beyond code. The scale of problems and impact assessment grew to envelope the software/development bit of it as one part of the solution, not the whole of it. Not that we succeeded in doing all we started to - but the neurons were pushed hard everyday, and the breadth of skills and ability to deal with fuzziness grew tremendously.

So much so that I became what I refer to as a "Product Manager". This is a much abused term and means a lot many things to a lot many people. To me its the guy who's got the 360 around a product in his head, and driving his life. Needs people to build, sell, hire etc etc - but the one who's marrying the strategic to the tactical, and keeping track of the story.

Linger is an effort at product management too. The code-writing is very different. But fundamentally, the ideas are the same. A product needs to be designed, created, tweaked continuously. The team has expanded, and the vision has grown.

What I've realized is that each plateau, there's been an urge to see if the problem solving effort made any real difference - and the next level was subconsciously desired, and found. Its not the coding, or the designs, or the rollouts that mattered. The question about what they became - or led to - eventually cropped up. Managing to score on somebody else's report card did not satisfy at all.

Is entrepreneurship the culmination of this ? Is this freedom to think, create, follow a path the ultimate path to satisfaction ? Dunno, but so far, its better, and I have found in me an urge to keep doing this despite its not insignificant costs. Amazingly, all the old rules of "hard work" (as measured), killer instinct, dog-eat-dog etc seem to not apply. Yes it still takes work and getting around a lot of procrastination - but those are by-products of a bigger desire, not drivers.

As always - "lets see how this goes".

Product Strategy & Management

While I'm working more or less fulltime on Linger I do miss the excitement of product creation (i.e. in the software space - Linger's a product in its own right!) and do think I have enough to offer towards this.

 

Of course I'm not likely to take up a "fulltime job" so please do not offer me one. I'm not looking at being co-founder and what not - thats a step one can take only after a decently long engagement and if all the stars are aligned. But I like solving interesting problems, and I like the challenges that product roadmaps bring. 

 

So if you think you're could do with some help/inputs on this front, ping me at get.sameer AHT gmail.com and let me know what you're doing.

 

Posted via email from workFront

New Idea : A Chicken and Tech Problem

I have a new idea that I totally think has potential, is worth pursuing, and building technology around.

The urge, as an engineer, is to first build the site + functionality, and then "roll it out". But after years of being in tech, and having seen many never get out of their comfort zone and, as a result, having built too much in isolation, its an urge I need to resist.

So the first tasks ? Go sign up the stakeholders. Create enough functionality and documentation to sign them up. then go find other stakeholders as users - give them just enough so they can appreciate the core value of the offering.

Then think of the code.

Product Management Workshop

Ashish (pluggd.in) and I (representing SlicedBread) are doing a workshop this Saturday, the 3rd of October, to try and get across a feel for what holding the the threads of a product from its conception to its maturity involves. Of course you're unlikely to become a great Product Manager (and I am still learning every single day!) simply because you attended the workshop, but it does introduce you to the structure around this role, indeed the very need for the role, and common mistakes we make during product development. Theoeore basic idea is to be able to connect the product development effort much better with the market needs as they're discovered, be able to respond to changes, and keep the costs of these cycles low.

More details here.

Product Identity Crisis ?

[ Cross posting from the SlicedBread blog ]

Ashish wrote a post about the importance of recognizing exactly what business you are in.

This cannot be over-emphasized during the early days of a product, or a startup. You cannot be nebulous about exactly what problem it is you’re solving, and for whom. The trick is to tackle this at as fine grained a level as you can (and not just at a we’ve-built-a-tool-let’s-see-how-its-used-level). If you cannot answer clearly enough for the first guy who asks this question to understand, its unlikely that users will see easily that its for them!

One trick I’ve found useful is to think in terms of nouns and verbs first when describing use cases, and avoiding the adjectives and adverbs. Also, pick verbs that can be acted out immediately – say – in a dumb charades or pictionary game. Or at least something multiple can clearly visualize as the same action or activity. “Evaluate”, “enhance”, “express” are some words that could be too ill-defined to capture or communicate a use case effectively. “Add as friend”, “read the shared content”, “rate the movie” are much clearer. As you start capturing it clearly, you will start debating the value each brings to your core idea more clearly as well.

And – this is my favourite take on all things computer science – its all about inputs and outputs. So given all those verbs and nouns, what does your product ask for, and what exactly does it give ?

Who are you ?

Update: One of my friends tweeted this morning (that I'd RTd) about FB's identity crisis. Quite relevant!

VC, Know Thy Fundee

The Venture Capital industry in the US has given extremely poor returns in recent times, and some consider it broken. I'm not sure what the India numbers are, but the focus, modus operandi and problems facing the space are similar, and in some senses, less effective. The huge factors in their favour are the relative stability and ever growing domestic markets (of course, for those focused on India, and more so for those primarily into the PE story), and of course tremendous cost tractability vis-a-vis the Valley, for instance.

Now, imagine:

Don Corleone invests in a million bucks into a "business" run by a fledgling caporegime in a territory with lots of promise. A few months down the road, the monthly meeting is in a dark room full of cigar haze with tough questions flying across the table, and the Godfather surprising the capo with info gathered from the street that the capo might be trying to hide, or gloss over. It could either end in the capo getting a thumbs up for establishing firm control, or a "Its strictly business" list of to-dos to strictly be followed for ensuring the family gets there profitably.

Or, a traditional business family in India pitches in to get a young chap striking out on his own in a new town/business/opportunity afresh. They obviously need to buy in to the idea, and measure progress often enough. They also dig up every source to keep tabs on where the markets headed, what the guy's reputation, image and credibility is as he engages with the market, and offer both advice and tips, as well as harsh feedback on specifics that is passed on immediately and well - transparently.

Thats how businesses get built, sustained, nurtured.

The Venture Capital industry plays an important role in discovering and nurturing new market opportunities. In fact, the businesses they try to help build are usually much larger than what an average capo or a family businessman would attempt at creating. These businesses need even more nurturing, and inputs. Theoretically, at least, the VC not only brings capital to the table, but also helps keep the ship on course, plugging the gaps as they're spotted. They can help engineer the right contacts, aid the best executive hiring, enable appropriate mentoring amongst others.

But then, there's a gap when it comes to those value adds, at least in the Indian context. Unlike Don Corleone, or the average business guy on the streets, venture investors often fail to connect with their startups' work - operationally, technically and sometimes even from a consumer/customer point of view.

The best understanding of the businesses investors have today depend on "other-investors'-opinions" and on their own take on it. Generation, technology gaps, lack of empathy with the target market, and an uncertain understanding of what's really getting built ensure that the meetings are once-a-month "updates" affairs, and the data collection is usually limited to what their protégées tell them. Sure there's some cross questioning, and the numbers sometimes start communicating the true story (often too late in the game).

But to be able to really relate to whats happening, whats right and whats not, and most importantly, what the options are from thereon, VCs would benefit from a deeper, independent assessment of the businesses they're banking on. And of course, the technologies, products and target markets those businesses are banking on!

There is a need for a role which can better understand the domain or technology that the startup is built around. This is truer for technology startups than the others, but there's usually something technical/domain specific about every startup (at least the better ones) that differentiates it. Most investors are generalists and connectors, because of which they bring together a wide array of skills, perspectives and contacts! Obviously, their understanding of what's happening inside of their portfolio companies, and what course corrections could and should be made, is limited to the level of a higher level business scenarios that can only make uncertain assumptions about the finer, and often crucial, details of the product or domain. And we do hear a lot that execution is everything!

So, how do investors get to know better ? Call in the experts!

To someone in the know, the red-flags show up all over the place as you dig a little! One hears of huge investments in companies build around technologies (sometimes mere features) that could be build primarily around commodity stuff that might even be free to download off the web. Other startups build vanity-features that are unlikely to see much usage amongst their target audience. And a whole lot of startups do not even figure out who this "audience" is, and at the same time worry about the numerous textures the product could have.

Then there are obviously numerous "high technology" stories where the potential is enormous, but the success is extremely dependent on both the core as well as the packaging and positioning of the product. A lot many might potentially succeed in one of many avatars, and would benefit from rapid experimentation enabled by flexible product design.

Clearly, VCs would benefit a lot if they got dope on some of the above, early and regularly. This obviously needs a continuously updated understanding, and measurement, of what their companies are doing. Every decision around the product feature and roadmap, its architecture, and even the robustness of the process through which these are arrived at, makes a huge difference to the product's chances in the market. These cannot be gauged easily from a short monthly interaction with the CEO. You need a sharper focus on the goals, and ongoing engagement at various operational levels to ensure those are being worked towards.

Goals

What are the companies goals ? Are the same goals visible to all functions across the organization ? Are those the ones driving value for users/customers ? For instance, you're trying to create a service that delivers content over SMS along with contextual advertising, and a product loophole that allows people to essentially send free SMSes to friends could be the one driving traffic!

Roadmap

Is the Product Roadmap in line with the goals ? Often, beyond the first release, nimble startups get into a reaction mode where every little piece of feedback from users, VCs, the media and other assorted sources is incorporated, and every little idea that comes from competing sites, or merely sounds cool, gets implemented. You end up with a host of features and functions that are no longer coherent or cogent to your primary USP, which was .... ? Obviously, even the metrics gathered start reflecting this, and there's confusion both externally and internally about what the product or service really is ? Crispness is key.

Team, Hiring, and its first cousin - the Burn Rate!

Funded startups are usually at risk! There's money, and folks now have the luxury of pursuing the various ideas that have not been able to get attention so far! Add to this the ability to right away target multiple groups of customers and consumers, do branding, create pitches and soon, you're lost in infinite activity thats gong nowhere. There's a need to link all spending, right from the size of the team, the skills needed, the necessity of doing certain things all together, to the goals and the roadmap.

Keeping the burn rate down not only helps focus, and it gives the startup get operationally viable sooner, and provides both the founders and the investor a lot of buffer!

Obvious Benefits

The returns on getting onboard an operationally focused team are quite apparent. An investor would do well to have help at hand for regular, clear understanding of what's happening in the portfolio companies. This would ideally be a team which brings in both technology and product management experience from a in-the-trenches perspective. The startup would get better help, better focus and probably leaner.

Quite obviously, whats better for the startup is better for the investor!

Data-Driven Decisions vs. Intuition : Is it really a "vs" ?

Its very hip to talk about being data driven, and as engineers, very appealing as well. Its also a more provable way of justifying a decision. User A/B tests on various designs prove it like no amount of brainstorming can, and clickstreams, sales numbers do not lie!

Yet there are majorly accomplished folks that disagree vehemently with the data-centric approach to decisions, and that makes for a good debate :). Here's a very good 360 around that particular one.

So, is the "versus" in the debate actually called for at all ? As engineers, do we beat too many things down with the data club ? (I somewhere suspect the opposite is not that strikingly true for designers, decision makers, etc who are seen as "following instinct")

Let's deconstruct this data driven decision thingy, shall we ?

You gotta decide about a product idea, or a sales strategy, or a marketing message. So typically, this is what you do (explicitly, or otherwise)

• Imagine who might consume the outcome of the decision
• Try and figure out something about the above set. Data ? Helps a lot!
• Take a call on what'll work.

The data is an input (and comes in many forms!). Over this input is a layer of interpretation, analysis and the final decision is a reaction to this process. Data can help decide, but data cannot decide!



At what level is the decision ?

Are you deciding about a UI attribute for an existing, popular product ? Sure, do bucket tests and let the audience speak. Is it about the product's copy ? Hmm, a little less black and white. The positioning and concept you're trying to communicate about the product ? Well - there's no getting away from hard work and decision making on that. If you expect data to always provide all the answers in black and white terms, you're likely to freeze when working on a lot of things at a more "zoomed out" level.

For entrepreneurs, its often a question of whether the product (which is usually the company itself) is working, and if its not. If you need data to tell you that, you have other serious problems :) Of course you will be going through data, and what we popularly refer to as "instinct" or "intuition" does not develop in isolation of data. On the contrary, its something you develop as you learn how to sift through data, read between its lines and deal with the apparent conflicts it sometimes throws at you.

Conflict ? Aren't numbers black and white ?

Are they ?

Here's two data points from an example I remember reading about recently (sorry, do not recall the source). A survey of numerous car buyers in India put safety high up there in the lsit of influencers for the buy-call. Yet the actual purchase decisions (vis-a-vis the information requests) for models with ABS, airbags or till some time ago, even those with seatbelts at the rear said it was not necessarily an important factor.

The case study surmised that the latter was to be believed, and the former to be ignored. Its probably a more trustworthy data point! So the models which get ABS etc continued to be those at the top end of the offerings.

There - you already needed to pick and choose, and not trust every bit of data as is. But is that all ?

Weren't the consumers also communicating an aspirational need, or one that got negated merely because the cost differentials between the (usually high end) models with ABS etc and those without were extremely high ? Would these people pay a smaller difference for the same in an otherwise lower spec'd model ? Is there a way to lower the cost of including the safety add-ons ?

Do you have enough data ? Qualified ?

Very often, a new venture, idea or product does not even have enough data to start with. Product and entrepreneurship decisions are full of these cases. You still do your best to understand what the picture is, and base a call on that. Would you like to base your calls on tiny samples ? Or would you rather ignore them, unless a clear message emerges ?

And them, lets say you launched and had a couple of hundred thousand clicks on a new page/feature. Of course, you SEO'ed, maybe ran an ad or two, and maybe got some initial coverage? What was the quality/value of those clicks ? Did they all come from ad-clicks, with little repeat usage? Are they from the right target audience which might help in engagement and drive usage/consumption of the important features? Should a transactional site be very happy if a lot of folks turn up looking for info alone? Should it be despondent ?

The clickstream is quite useless during the early life of a product unless qualified. Yes you can collect more data for it, but each qualifier and context for data that you measure stems from a judgement call about why a number is important, and when must it be factored in. Of course, again, you can create a analytics framework to crack that as well, but at some stage or the other, its impossible to keep out human judgement and interpretation of data completely.

Its not "data vs intuition".

There's a huge risk to merely following data - in case you've not set the right context. You can be lulled into a sense of safety/driven into panic needlessly merely because the data says you doing great/horribly, and you forgot to try and see whether you were missing some part of the picture.

Data is only about the stated. The rest is conjecture or extrapolation!

Extrapolation (quite like analogies :) ) is a pretty strange thing.

You can collect data about what's out there. What did the user leave unsaid? Did they like your logo? Why did the dropoff happen at some point ? Did something trigger a word of mouth ? What about the not-clicked links - why did those get ignored ?

Some will need another round of hypothesis and data collection. Others will need some level of an educated guess so you can move on. You've got finite time and resources, and your product is not a grant funded lab!

Data is valuable. But the value is elsewhere.

A lot many great businesses have been built on instinct. That does not discount the research they did as preparation, or the amount of information they might have collected. It only highlights that the ability to make a decision with whatever is available is far more valuable. With the same data, the same inputs and for the same scneario, there will be multiple decisions that succeed to varying degrees, and numerous possible ones which might fail. It is an art, and the attempts to reduce it to a science can only work for low-granularity decisions, and that again for existing, running-state stuff.

What's probably more critical, and to be practised to improve one's judgement calls, is to actively seek to verify hypotheses through launch-and-test iterations, and do these cheap. Developing a good sense of what data to collect, how to read it in the context of other numbers, words around it - this will serve you much better than being a data driven automaton. Its a great help to have numbers, but remember to use them both judiciously, and honestly.

Its not yet time to let the machines take over ;)

SlicedBread

Its been a month!







I've gotten together with a couple of other people who're Gurus at understanding various aspects of Products - strategy, positioning, technical understanding and roadmaps, analytics, etc - and created SlicedBread. The idea is to - oh, well - there you go...

Smaller, cheaper, faster

I've come to believe in this philosophy for starting something, and here's some more support for the cause. (From Getting Real - a book by 37Signals) (Thanks Sid, for the link)

The main advantage that I think comes from working under constraints:

"Constraints also force you to get your idea out in the wild sooner rather than later — another good thing. A month or two out of the gates you should have a pretty good idea of whether you're onto something or not. If you are, you'll be self-sustainable shortly and won't need external cash. If your idea's a lemon, it's time to go back to the drawing board. At least you know now as opposed to months (or years) down the road. And at least you can back out easily. Exit plans get a lot trickier once investors are involved."

From even a product management pov

"Think hard and determine what's really essential and what you can do without. What can you do with three people instead of ten? What can you do with $20k instead of $100k? What can you do in three months instead of six? What can you do if you keep your day job and build your app on the side?"

Give it a read - the whole book's available online - free. Of course, there's a world of effort, training and belief between knowing it and living it. But there's always somewhere you start....

Great at less than 100%

Ziva is a very "dynamic" company, to put it nicely. There's always a dozen ideas, and another 10 underway, and plenty of possibility. Each idea has a bright blue sky story to it, and in its ideal avatar would yield phenomenal improvements/data/users/glory/whatever.

The big questions I've learned to ask is : What happens if the idea doesn't mature to its 100% ? Is it useful/worth doing/helpful to the product and direction at 50% ? 20%? Whats the first version and will it be something we can make use of in itself ? Is the "prototype" a product in itself ?

This isn't an execution issue. Its just practical. From what I've observed in the software world, rarely is an idea executed to its fullest ideal. There are engineering issues, time-to-market issues, other priorities, reactions to real need that create directional changes, etc, that all lead to a smaller subset or version of the idea being the end-product for the longest time possible. This is also a good thing - because it leads to practical, usable R&D rather than early, limited "lab prototypes" that don't really fit anywhere yet, but "we're working on ver 2". It also gives a feature/product a shot at collecting market feedback early, and helps optimize resources on it. Most importantly, it reduces wasted effort on half-bakery stuff that never got released. Sure, we still have a lot of those, but thats where the learning happened ;)