Category Archives: product management

Why I am still excited about PaaS

Remember LinkPeelr? It’s a Chrome extension I built over a lazy weekend over two years ago, and it has since been featured on Lifehacker, Mashable, MakeUseOf and many other awesome review sites.

In terms of active users over time, this has been the most successful of my projects, with over 3000 people using it every week to see where short URLs lead without having to click on them. It’s a great little utility that I still use it every day. I couldn’t sing it enough praises, so I’ll let you try it for yourself instead:

Download LinkPeelr extension for Chrome

Recently, I started thinking of marketing strategies (growth hacking is the term de jour, I believe) to take the extension to the next level. In the course of my investigations I’ve learned that extensions actually “know” when they are being updated. So then it hit me, why not use an upgrade event as opportunity to learn something about my users, namely why not open up a new Chrome tab and ask users a few questions about how and why they use LinkPeelr.

In a stroke of genius I added some code to the extension to open new tabs whenever it detected being installed or upgraded. This was a couple of months back, and then last week one of the users reported a critical bug that I needed to fix right away. When I deployed my fixes, I inadvertently deployed my half-baked survey-tab-opening code.

When a new version of an extension is released it is seamlessly deployed by Google Web Store to all of the extension users. Over the course of 2 hours 3000 people got the upgrade, and their extension popped open a new Chrome tab.

The problem is that the half-baked code also pointed the tab at http://linkpeelr.appspot.com/?v=2.0.1&new_install=true. Each http://linkpeelr.appspot.com page also shows a  live feed of what links are being peeled by other LinkPeelr users, which results in one API call being invoked every 3 seconds from every open tab.

Here are the results:

Google App Engine traffic spike

Google App Engine traffic spike

The beauty of platform as a service model (PaaS) is that have I not accidentally looked at my Google App Engine console I would have never noticed what was going on. The platform automatically scaled from 1 instance that it normally needs to peel links for 3000+ users to 5 instances to handle the additional API load. And this was still well within my free Google App Engine tier.

I had a little “oh, shit” moment before I commented out the offending code and deployed a new version of LinkPeelr. It took all of 5 minutes to resolve the issue.

Don’t get me wrong, there are plenty of cases when PaaS just won’t do. As for me, I’ve used it for every single one of my side projects and have been consistently pleased with not having to administer any machines or worry about minutia I have no bandwidth for anyways (pun fully intended).

So why not use Google App Engine or Heroku for your next big idea? If you can skip the micromanagement and use that time to focus on the product, why wouldn’t you?

Please let your product passion endure

There is a natural continuum between an uncompromising idealism of a starry-eyed, first time founder, and a jaded cynicism of someone who has already found a winning formula and is prepared to apply it indiscriminately. I’ve seen an expression of both extremes of passion in my conversations with founders,  managers and product people, and I’ve seen it come across vicariously through the product itself.

What so often begins as a passion for a product and exceptional user experience turns into a passion for profit. I am struggling to express what, if anything, is particularly wrong with this tendency. After all, everyone needs to make a living, and passion alone cannot buoy every single product. It’s brutal out there, and when the money runs out, it has the inevitable effect of also smothering any passion to make something great.

But the converse is also true. I feel like far too many products and far too many judgements never leave the dollars and numbers dimension. There is almost a criminal lack of concern for the user experience or user value, and this comes across as wholly unjustified and offensive. The respect for the user is gone as soon as the product person starts saying things behind the user’s back that they wouldn’t say to their face.

It’s especially disconcerting when an attempt is made to make the business piece fit while the product vision hasn’t had a chance to take flight or even fully form. And I really wish there were fewer of those personally gut-wrenching moments when I see passion compromised for something not worth the paper that business model spreadsheet was printed on.

In case of emergency, press this button

Spending four days without power last week left plenty of time for quiet reflection. One thing I thought about during this lull was our society’s reliance on critical infrastructure and the products and services we’ve built around it. There was a great write up last week musing, among other things, about our willingness to pay high multiples for essentials in times of crisis. I could have made a similar case about hot water and cell phone service, but as I thought about it more, I kept coming back to the same question:

What defines critical infrastructure, and how do we come to rely on it so much?

Continue reading

Common Sense Is A Trap

When was the last time you paid for an idea? I know, I know. Who does that? The information wants to be free and most good ideas are already on the Internet or Wikipedia. A lot of these ideas are public knowledge. Humanism is an idea. Free choice is another idea. Constitutional monarchy is an idea. Individualism is an idea. Why would you ever need to pay for them? Continue reading

Careers in Product Management: A Generalist’s Lament

When I interviewed for a technical product manager’s position with my current employer I was asked if my background managing a low-power wireless networking stack for embedded devices with 128K of flash would be transferrable and appropriate for a company who provides educational software sold to school districts and running on large enterprise-scale systems in the cloud. I said ‘sure’ it can.

My argument ran that a good C engineer could become a good Java engineer. The good in the engineer does not come from his knowledge of a particular programming language but rather from his aptitude for abstract thinking, ability to decompose problems and to work as part of a team. A good product manager is a good product manager. Whatever the product vision is (and whatever the product is) it needs to be articulated in simple terms to audiences internal and external, it needs to be launched, its performance and metrics tracked; it must be squared against competition and it must be decomposed into a set of requirements and priorities for the engineering.

Admittedly, in making this argument then I put my own interests ahead of the truth. I’d be lying if I told you that I didn’t worry that once I transitioned into this new universe there would be a huge learning curve to overcome, much like there is a huge learning curve to overcome in going from C to Java. I also knew that the chances of this hypothetical C developer being hired by a Java shop were  infinitesimally small. “How much better were my chances”, I wondered?

Whether through the sheer powers of elocution or luck, the chances turned out to be much better indeed. I was hired, and the transition I worried about for myself has gone off without a hitch. I’ve now been in my new role for 6 months, and I don’t feel particularly disadvantaged by my background to be in this very different domain. And that’s the essence of my lament…

Is there something intangible about a market that my 5 years of experience failed to surface? If I’d been in embedded for 10 years, would I be less capable of making this transition or is it all ultimately the same stuff? Are we, the product managers, just delusional about our so-called vertical expertise and are our skills more interchangeable than we care to admit?

If this is indeed the case, count me disappointed. It means that either we can never become exceptionally good or that there is just isn’t that much that’s specific to any one product. While there is still no limit to how much experience and expertise we can accumulate, would this observation imply that it doesn’t matter where we do it or whether we hop across multiple domains in the process?

Does proficiency mean you stop learning when you get good?

Lately I’ve been doing a lot of thinking about proficiency and skill. Where does proficiency come from? How can we quantify and measure it? How is it different from skills that non-practitioners have?

So here are some of my thoughts. You are fully entitled to vehemently disagree.

Continue reading

Technical debt is a rabbit hole that goes deep, really deep…

I don’t care how brilliant a developer you are, every piece of code you will ever write will add to technical debt. Yes it will, and it will irritate you to no end.

White Rabbit

Technical debt is one topic that instantly sparks debate and ignites controversy. I see the talk of technical debt crop up at work (even though we are still in the earliest stages of the project and haven’t accumulated much), and I see the need to manage technical debt in the code I write myself (even if my projects relatively small in size).

I believe what makes technical debt a development pain point is the fact that there are literally endless ways to continue to improve, optimize, refactor, enhance and generally better the code. Since most capable developers are perfectionists, these opportunities for improvement are a persistent and nagging temptation. It’s an issue that can affect productivity, team morale, and that has direct implications for the business value you are trying to extract from your team’s work.

Given the importance of the topic, I thought I’d share my own perspective and experience managing technical debt in a constructive and healthy way that still makes business sense. If you are lazy, you can skip to the “definite DO’s” at the end of this article.

Continue reading