Productivity vs. Dependance

A recent comment from the online SaaS class has fired a not-so-pleasant memory. And a rant.

It wasn’t a pleasant summer(of 2006) morning in Hyderabad,India. The sun was up early and by 9:00AM it was 45C, the drive to work must have sucked for all of us in the engineering team of the CRM product at ADP India. Well, add to the effect, bad news was waiting. Microsoft has released a security update for the .NET platform and it broke all our code.  XML structures weren’t right, the UI is all messed up, most data wasn’t reaching the UI. For our customers in the west, this happened during business hours and that was a big blow. They kept calling our support and it took our engineering team in the US some time to figure out what happened. Microsoft had been really sweet in responding quickly and fixing the update that apparently didn’t cover the test case for certain scenarios (for NDA reasons, I’m not able to go into fine detail here. sorry.). But for the customers, quick wasn’t quick enough.

As a just out of college grad, naturally in love with the third generation(hell yeah!) languages and tools, this was too much for me to handle. The hard fact of life: When you’re greedy for productivity, you end up creating some dependance on the vendors who provided the cozy platform you worked on, that promises “fast and reliable app development”. In the above scenario, we could fix our SaaS offerings rather quickly by undoing the update. With the others who hosted their own copy, things were a bit tougher. Ofcourse, I’m not disagreeing that there were things that could have been done in that scenario to avoid it. But isn’t it so much better not to have the dependance in the first place? Or rather, what’s the cost of using a third party platform/language/tool for increasing productivity?

Let’s  say you’re using node.js – It is built on Google’s Javascript runtime which shows 443 open issues at the time of writing this post. I know this number is a blatant generalization but it does say something about the app you wrote being dependent  on stuff you have no control on. Another aspect of software engineering that has the same outcomes is code reuse. In my experience, I’ve seen people build proprietary libraries for handling common tasks of a web application (like error handling) rather than use stuff like Enterprise Application Blocks. Obviously, there are reasons why the NIH syndrome has its place in the industry today.

In the age of Saas, shit happens real time. And guess what, billing happens real time as well. This means you’re losing money every minute your app is down and you most certainly don’t want it happening for reasons you can’t fix immediately, or even worse, for the bugs that you can’t fix. What’s a good solution for this? honestly, I’m yet to find out (your comments will be appreciated) but I’ve heard of weird stories from friends,of  products that have multiple implementations for a fall back option(yes I’m taking of the same app being built in,say, Java and .NET). Most of the time, its not as bad as the case I was involved in – by being alert and informed and with some preventive measure, disasters can be avoided. So that brings us to this question:

how much dependance on third party platforms/languages/tools would you allow in building your app? what factors would you consider for making decisions such as build vs. buy/borrow the technology needed for your app? how much dependance would you allow in the tools that keep your app live?

What went wrong?

First, Hello world, after a long time. Last year’s time wasn’t quite suited for blogging (lets not go there..) and here I go again, first post in 2012.  I came across a good read on 37 signals about entrepreneurs explaining why their products failed. Ok, so seriously, there were like four reasons from all the products. Letset down to detail on each –

1. We didn’t build something that people would pay for:

To start with, I hate this heading. That’s not how it should be put, although most CEOs did. They should have said “We could not find revenue models for our products. Most of the damage happens when people start out on a product without realizing the answer to one question: where is the money?  Verifiable’s CEO Stuart Roseman explains in his own blog at length how this could happen. Besides that, many entrepreneurs in the article quoted above seem to explain how their idea was such an incidental success and how the idea of monetizing it never occurred until later. I’m sure they’re all tempted by the big daddy of incidental success – Twitter. Well, now we know that it doesn’t always happen.

Some(like vox) seem to claim how the product was so useful but could never be sold. Well, if it is a useful tool, it will make money. There’s a way to sell anything. C’mon, hasn’t Twilight the movie made any money?

A very good product management lesson in here is to figure the ROI of every feature of every idea that comes your way and to not waste time and money on building it before you have your numbers up on, at least, a spreadsheet. If it were me, I’d hang that spreadsheet in the kitchen.

2. We got beaten by competition:  Wesabe’s former CEO Mark Hedlund writes the gripping story of how Wesabe lost to Mint in his blog where he busts many of the most common myths about competition (and to my amusement, many they teach you at b-school as well). He goes on to say how Mint’s approach on the product kicked Wesabe’s ass, and how that became the biggest loss for Wesabe. As a keen user, I could have observed similar stories when Gmail beat Yahoo! mail and when Facebook beat Orkut. ’nuff said.

3. Didn’t know our users: This is Swivel.coms story. And Oh, its such a product management failure, I’m doing an entire post on this.

4. We changed our focus on to another product: Bingo! they taught us this at b-school. Google did this with all its expiring labs products. In a way, this is letting your product get cannibalized by another of your own, pretty tough to pull off in smaller company cuz it beats the morale of everybody involved and better be a collective decision rather than the management’s own. In bigger companies however, the developers manage to find some other product of their interest which makes moving on easier.

Whatever be the reason, its always a tough decision to shelf a product or a company thereof. Most entrepreneurs are forced into it after running out of venture funds. They say failures are stepping stones to success, which is true in this case too when you look at it from an entrepreneur’s life but for many others involved including the venture capitalists, a failed product will be that bad dream that you can’t quite get over.

Keeping up with change- part II

If you’re into product management and would like some entertainment, I’d suggest watching The Pentagon Wars. If you already did, here’s a good refresher 🙂

Hell yeah. Bradley,FTW.

Alongside the funny part, that has some real facts you’d encounter everyday as a product manager, particularly when you’re customizing a product for someone. Yes, and I’m going to talk about stuff related to “change” here. If you observe closely, most of the requirements the General mentions in the meetings are genuine. General was willing to encourage a new idea. All he wanted was his scout. If you’ve ever worked in the product management in an agile environment, you’d know this situation. Whenever there’s a new idea being discussed, there’s always the “last in the pipeline” idea waiting to be implemented. Most of the time, the product manager is forced to take tough decisions about what should to go into the release and what shouldn’t.

Also, there are some classic lines you’d relate to. Here are my favorites

“So the configuration is wrong”

“Looks like a design issue”

“Can you make this thing amphibious?”

Now, that’s the kind the change I was talking about. What was design was later an issue. What was configuration was later a problem. Blame it on the change.  Often, these situations need more complex solutions and require you to think out of the box. I’ve never seen a project on which budget wasn’t a problem which means learning to deal with it is the most important skill you’ll ever need out there. Take a closer look, find the opportunities, try and fit them in the budget. There’s always a solution. For Bradley, maybe it was build a troop carrier with aluminum and save money for a scout. In my personal experience, it did happen that some times you realize an opportunity when it’s too late.

There is more stuff in the movie that product managers can relate to and of course all that is presented so well, you wouldn’t really laugh when others do 🙂

Keeping up with change

Hello again, world. It has been a long time since I blogged.  This was partly due to traveling and partly interviews. There have been days I had time on my hands but was facing a writer’s block.  However, this interesting question from a recent interview triggered some thoughts I want to share on my blog.

I faced the usual question in a recent interview – “what do you think is the toughest challenge in product management” and my answer was immediate – “predicting the future of your market”. Then came the nicer question “oh yeah? how do you deal with that”. Frankly, you can never completely answer that question.  There are some scientific methods, some proven ones to satisfy temporary needs, but oh if only you had the visions of future….

Think about this – the basic philosophy is, your wants keep changing everyday.  I want Pasta tonight. I may not want it tomorrow. Even if I don’t get to eat Pasta tonight. Or lets say I crave pasta tomorrow as well, but there’s freshly cooked Indian at home and that outdated the pasta craving… you get the idea. Customers’ needs keep changing so quickly, by the time you gather requirements, put together all the documents and build a feature, they don’t need it anymore. I’m sure you faced this atleast once. How do you avoid this?

The easy solution – Be a visionary. Yes. For those who can’t do that, here are some unconventional ways that have proven worthy in my experience.

Stay ahead

My most favorite saying, “the best way to predict future is to invent it”. You put yourself in the customer’s shoes everyday. You as in, the product manager, and everyone involved in building the thing. Constantly try to understand “If I’m the guy using this product day in and day out, what would be a cool thing to see next”. For that to be done efficiently, you need to use the product everyday. One thing i used to do as a developer is, play around with the product during breaks and while doing this, keeping the code and the architecture completely off my mind. This helped me understand why i was writing a certain piece of code a certain way or why my architect was giving me those directives.

So you build an outline of something you thought would be cool as a user and you release it to your colleagues, then to some of your customers. By this time, you’ll know if it sucks. If it doesn’t, it’ll sure define the future of every product in your product’s breed.

Track the current usage and do the math

This is a good thing to do, particularly if your product is B2B and your customers are ok with some usage data being tracked. You get to understand which of the features are doing well or being most used. Then you drill down and do some predictive statistical modeling and apply common sense. A lot of business school grads will tell you to use excel sheets of numbers here. I don’t advise that personally because looking at just the numbers, you’re more likely to be deceived. Use a statistical model like a neural network or CHAID. Note that this modeling can also be done on excel.

People often bet on the second option more than the first, solely due to the numbers involved in it. However, most successful Angel Investors believe in the first, that is, going with the  feelings of the customer. I think, a combination of both should work based on how much time you have and how the effort is aligned with the goals of your business.

Happy new year

Belated wishes, but better late than never!

Happy new year, readers. Hope ya’ll had a great new years eve. Mine was extra special cuz my brother got married the night before new years. I loved the wedding. Besides that I’ve been having the most amazing biryani, coffee and fun time ever.

Thanks everyone who commented on previous posts and pages. I need to “moderate” them lol. Something i couldn’t get around doing. Cant wait to get back to Chicago!

Rollercoaster

A new Idea or a feature in an existing product is as much a roller coaster ride as a startup.  The investment-incentive elements are the same, except there is much less work involved. If your product is in a space that’s not really mature(like CRM for automotive dealers), there’s always the buzz in your team about what the next big Idea will be and how it would keep you ahead in competition. But hey, that’s not what product management does everyday. They have among others, maintenance stuff (phasing out outdated features), keeping up with competition, user surveys, quizzing etc. However, when a cool new Idea comes to the table, everybody goes through a cycle. Described as the  Transition Cycle by  TimFerris, every idea goes through 5 phases in the minds of people who pursue it.

People associate this cycle to startups, mostly. However, I think this applies to every Idea out there – new features in an existing product, business innovations, or just a simple maintenance idea. In my experience, most bad decisions are made at the “crisis of meaning” phase – a phase which is easier to deal with if your product idea is backed by a big company with lots of money to risk. I’ve been in this scenario so here’s what its like to pass through every phase:

UnInformed optimism: Product Marketing has a new feature Idea for the next release. They’re at a conference/show and they’re talking to visitors to their stall about this cool new feature that’s going to be a part of the next version.  (not so) surprisingly, they haven’t discussed this with Product development yet. They know (=have assumed) this can be implemented and distributed to customers on time.  This is exactly the picture the senior management has.

Informed Pessimism: Ball is in Product development’s court now, the realities are kicking in. By now, the very learned Product development team has seen compatibility, implementation and maintenance issues. The deadline isn’t matching the product release date, however, they’re trying. Scrums are failing, the burnout  charts aren’t bringing any motivation to the table.

Crisis of meaning: The most dreaded phase, this comes in every shape and size. As a developer, a business analyst, an architect, yada, yada, yada, I’ve had different experiences of this phase in every role i played across various teams, dealing with various products. The most common symptom is finding yourself wondering if the ordeal is going to be worth it. Yeah. Also the time during which you face the most surprising surprises.

• The product is out there but the infrastructure  is failing.
• people aren’t buying your feature
• The media, like blogs and forums aren’t giving you good word-of-mouth
• You can’t keep up with the usage
• your competitors surprised you with a better version of the same feature

Here’s the decider set, right before you. You win it – game,set and match. you lose – you’ll probably be in the fight for a while but chances are, you’ll Crash and Burn.

Informed Optimism: This is where the last few minutes of the coaster ride. Obviously, you enter this phase only if you cross the crisis of meaning, and have realized the knack of selling your feature. You’ve heard from your major customers and they like it. You’ve overcome surprises by figuring out smart ways to get around them. You know what sells, for real. The PM team is proud, Development team is partying, Maintenance team is busy and the Customer is happy, while asking from more 😛

Crazy time

These are crazy times. My blog hits are going off the roof this week, reasons unknown to me. Also, while I’m busy getting ready for a big vacation (and trying to get the best out of the holiday deals),  there’s a spike in phone calls from employers. Today alone I had 2 new leads for BA/PM position who wanted to  interview me before Saturday, when I start my vacation. Plus there’s life as usual, that keeps you awake until 1:00 AM . Somebody suggest me an effective time sharing algorithm!

Its interesting that most of my prospective employers talk about this blog. Not surprising, but interesting, considering this is still a baby. Whats more interesting is that while the readership is soaring, there are  no comments yet! I’d love to see some of those 🙂 I’m constantly talking in my head about new ideas, improvising the old ones and wishing I had more time to blog more and do my research more. Bay area life was warmer and slower for sure.

With the job search getting busier (meaning i come across more job descriptions than I’ve ever handled) the questions about what do I want now and what I’m ready for are coming to the table everyday. For starters, I want to be a product manager or a business analyst. Funny how  sometimes you’re expected to have some experience stamped on your forehead before you can deal with new ideas or think big.  Wonder what would have happened if Shawn Fanning or PG ever thought so.

use-a-thon

You have a great product. In the  pursuit of marketing your product, you’ve been to countless conferences, annual shows, put up videos on the internet, conducted fests and done weird stuff.  Nothing works like getting the audience use the product. Even better is to get them use it intensely.

What

A use-a-thon is an intense improv session where a bunch of users solve a really complex situation using your product. The user with the best solution walks away with an incentive. “Best” depends on what you’re measuring.

How

The Idea is to create  the most challenging scenarios in which your product would be best used, often making sure it involves some thinking and going through complex workflows to crack it. The degree of challenge should be carefully set based on your target audience. Use-a-thons  run from just about a few minutes to an hour.

There are many things you can measure, like

• The most creative way to solve the problem at hand
• The fastest way
• The slowest way (yes!)…..and
• The most popular way.

A committee measures the parameters and decides the winners, and one or a few users walk away with an incentive (a discount on the product, an Ipod?) . The rest are offered more inferior incentives(tee shirts, coupons) if they choose to give feedback then and there. This feedback matters and is often more relevant and informative than stuff people write on your support forum.

You can also make randomly chosen teams of users. Often times,  this has better results than single-user plays.

Why

Why a use-a-thon? because nothing works like an emotional/intellectual encounter. Its like getting stuck with a stranger in a situation. You’re more likely to become friends with that person than the most attractive one in town. Besides that, a use-a-thon has its effect on all the participants.

• The winner(s) is/are happy. They get public praise and attention. The good feeling stays. They use the product and are likely to recommend it to others.
• A part of the rest will go back home and try to solve it later, opening up the possibility for them to get used to the product or explore more options in it.
• People who couldn’t solve it at all will tell you why they couldn’t. This is by far, the most useful output of use-a-thon.

Where

The place to conduct a use-a-thon is at a conference or a fest, if you have access to the required infrastructure. People are there to tr your product, so why not challenge them a little? The next best option is to conduct online use-a-thons if your product is on the web. It takes some extra effort and bucks to get users sign up for your use-a-thon, but that, in most cases is cheaper than getting a booth and infrastructure at a conference.

You can have it in your backyard, invite friends over. Just make sure they blog.

Google is promoting its version of an online use-a-thon called demoslam except it is much more complicated than the normal use-a-thon.

EDRM, lots to be done

My recent encounter with the EDRM space has changed everything.  It didn’t take me any time before i realized the passion i developed for it and after some market research and reviewing the best of the breed products like kCura’s Relativity, I could get an idea of what has been done and that triggered my thinking about what has not been done yet. Trust me, there is lots to be done. Here are some ideas that I’m currently thinking about:

Automation: As of now there are tools that make a reviewer’s life much easier, but there aren’t any that help in the actual review. It is safe to assume that to an extent, all legal cases need certain amount of similar work be done before any production happens. This part of the work can be automated. one example is to develop the most searched keyword list for every kind of case and use this list to “rate” the top 25%  documents that might go into production. This predictive analysis helps the reviewer to eliminate unwanted work.

Usage Patterns:  This would be a tool for the firms that make EDRM products. A tool that would track the most used “features” of the product and classify the usage according to the type of the case being dealt with. This tool not only helps product management, but would also provide the flexibility in licensing the product – meaning the company can bundle only the most used features for that case and license it for a lower price. This gives the users more flexibility and lowers the cost of the product, while giving the same quality.

Intelligent Internet Research: An add on to an EDRM product that reads patterns from documents that go into production and performs “similar concept” search in the internet space and open up infinite possibilities for the reviewer. There is every chance that a missing link could be found, or atleast a similar case or its history that would guide the reviewer in the review process.

There are more ideas at this time in my mind and I almost figured the way to implement and sell these ideas. My Intention is  to pitch these Ideas to Venture capitalists during the early 2011 funding cycle and see what happens. While these ideas could be valuable contributions to the EDRM world, I see them as them as the next big thing in the market. Time for some number crunching!

Chicago!

Yay! I’m in Chicago after four months! ah, the smell of Chicago. As i was riding in a cab from the airport, the sight of snow and the clearly marked road signs on I-290 made me happy (yeah, after spending a week in Boston, I have this new-found respect for Chicago’s highways and roads). The weather is mean as hell though. This is expected of chi-town around this time(and something I’m not new to) but winter is something you need to get used to, slowly. You don’t enter into 13 degrees from a warm 65 in Santa Clara and adjust easily.

I get to stay warm in an amazing lake view apartment, thanks to my buddies Ashika and Ari. Plus there’s hot coffee on the counter everyday when i wake up. That isn’t helping my urge to venture out and *do something, particularly cuz I’m on Michigan Ave. Oh well. It can wait for a warmer day.

I still see snow on the roads, which means the city hasn’t spent money on salting them this year too.  C’mon, we’re not in the thick of a recession! add to the effect, the city has banned street parking in the night which I’m sure is going to cause lots of annoying logistics problems for many people.

Tomorrow, I get to meet folks at kCura, the company that i had last blogged about! I’m looking forward to that. I also get to catch up with some of my ol’ UIC mates this weekend. fun time 🙂