Goodbye, IBM. Hello, Pager.

Goodbye, IBM. Hello, Pager.

I will be resigning from one of the best product teams in Watson Health in a month. It was one of the toughest decisions I’ve made in my career thus far. We have an incredibly talented and passionate team in Watson and Watson Health; I am confident that our teams will continue to make strides in the realm of cognitive computing and make significant contributions to stakeholders within healthcare and life sciences. I am excited to join Pager to continue to work on the matters I care deeply about — improving access and the quality of care for those who need it at a fraction of the cost for all those involved.

As I look forward to the many years to come with my new team @ Pager, I can’t help but reflect upon the time I spent at IBM. Consider it my tribute to the incredible 5 years I spent at IBM.

Ex-Glorified Security Guard @ IBM

I joined IBM back in 2012 as a strategy consultant in their consulting business (GBS). I was young and ambitious. With a Duke degree under my belt, I thought I could quickly prove my “worth” to the Partners on the massive implementation project which I was staffed on. Oh boy was I wrong. Before it hit me, I had spent the first two months of my consulting career checking folks in and out of the front gate at the client site. That’s right. I was getting paid a consultant’s salary as a glorified security guard (with two Thinkpads). This is an experience I’d never forget — not because how much it “sucked”, but what I learned from it.

IBM has been an unforgiving, stern teacher for me. I had grown up accustomed to opportunities that would land in my hands simply given my background and “pedigree”. I had grown up with the assumption that because I am “smart”, people would naturally place their trust in me and allow me to take on responsibilities worthy of my “brilliant” mind. Boy oh boy was I wrong again.

The two months I spent checking people in and out of the front gate gave me a lot of free time. I’ve gone through the concept of my next 5 startups during that time, but it all changed when I decided to cross the “unspoken boundary” and reached out to one of the exec leads, Olga Hernandez, on the project for advice. It’s a piece of advice which will follow me for an entire lifetime.

Olga is a tough exec and professes that tough love makes great professionals. She didn’t give much thought to my full-ride to Duke and my startup background; instead, she simply asked me to “show” her how I can contribute to the team. Instead of waiting for great opportunities to land in my lap (because I had assumed that my resume is more than enough to command attention), she challenged me to make a case for why I deserve to be trusted. My career had never been the same since that fateful day in that dingy conference room at the client site with Olga. In the year and half I spent with the project team, I had worked my way from the said glorified security guard to a tester on the solution testing team (think Mechanical Turk tasks), onto business analyst team, and eventually to owning the financial and resourcing plan for the $200M project, working alongside our project Partners.

During this time, I’ve learned to appreciate IBM — this century old organization — in a new light. This is a tough company with a tough-love culture. With more than 400,000 employees, this is the kind of company where young professionals would easily get lost in. This is the kind of company that doesn’t spend a lot of time baby-sitting new professionals along the way. This is the kind of company that will question you every step of the way — “So what are you going to do about it?” And I am grateful to have been a part of this beginning, and through it, I’ve learned to earn the trust and support of my colleagues. I’ve come to believe that this trust should be earned. I couldn’t have done it without the support of those on the team who believed me, invested in me, and took me under their wings — Olga Hernandez, Bing Zhang, David Carrico, John Toms, Bill Athey, and many others.

Babysitting Watson

I was extremely fortunate to have had the opportunity to join Watson when it was still in its infancy in 2014. Many of you might remember the Jeopardy moment when Watson defeated Ken Jennings and Brad Rutter. Here is Ken Jennings’ take on that experience. It was a signature moment in IBM’s long history — the kindling to what we have today. Despite plenty of excitement around the power of “Cognitive Computing”, Watson was nevertheless a nascent business built on top of relatively unproven and poorly understood technology stack. We had an incredible challenge in our hands, and we were missioned to take it head on.

Watson was the best two years of my professional career (so far). We set up the shop with literally nothing but a promise that Watson will fundamentally change how people interact with information. Without a second thought, I had taken up the healthcare vertical given my passion for the problems in this industry. Thanks to the IBM marketing machine and the $100M carrot in venture funding, we received more than 5000 “applications” to partner with Watson within the first few months. Nearly 1/4 of these interests were healthcare and life sciences focused. Many of you who have been keenly following the digital health space for the past few years would recall the rise to prominence of Rock Health and dozens of incubators/accelerators focused on digital health during this time. It was truly the best of times, and the worst, considering the amount of due diligence that is required to make sound investment/partnership decisions. Ask any investor in the space during this period. You’ll certainly get an earful on the “caveat emptor” around how “unique” the healthcare business really is.

So we went to work, and heck did we work. I remember spending months in back-to-back conference calls with hundreds of companies big and small in the healthcare space, with discussions spanning from the problems identified by our prospective business partners to the details of working with our Watson stack. It was a fascinating world for me, where I get to spend about part of my time doing “business development”, part acting as a quasi-solution architect, another as a member of the VC team, but all focused on the problems we’re looking to solve with the business partner. We worked with countless companies which culminated into many fruitful partnerships — wellness optimization with Welltok, cognitive veterinary care with Lifelearn, deciphering rare diseases with ThinkGenetic, and understanding effect of PTSD in returning veterans with Tiatros, just to name a few.

With the help of our partners and clients, we proved the business case for Watson. We proved that “cognitive” can be, and should be, a force to be reckoned in everything we touch in the years to come. The work around healthcare became so successful and visible that the mothership invested in standing up an entire business called Watson Health nearly a year later. To make the story much more interesting, many others (Microsoft, Deepmind, etc.) followed us in hot pursuit.

I am grateful to have been trusted with the opportunity to work with some of the most incredible people on both sides of the avenue — inside IBM and out. I’ll always be thankful for the call from Will Sennett which led me to the amazing two years at Watson. I’ll always remember the many hours my mentors — Lauri Saft and Jodie Sasse — spent training me on the best of the best practices for IBM Sales methodology and business development practices. And Steve Gold — our fearless leader who led the charge for us all — I’ll hold the wisdom and advice you’ve imparted on me dear and close to my heart. We’ve opened up a whole new chapter for Watson, and there’s so much more to come.

Scaling Watson x Health

We have a problem. We have an unparalleled narrative. We have a mission which we firmly strive towards. We’ve arguably got some of the best technologists who we rely on and a stack that has been proven out by our collaboration with our partners and our clients. Yet, we still needed to scale. This was the problem we set out to tackle when I assumed my role in product management when Watson Health was just starting out. With competitors hot at our heel, we had to ask ourselves the following questions:

1. In a world where “cognitive” technology — AI, machine learning (ML), natural language processing (NLP )— is becoming increasingly commoditized, how will we differentiate ourselves in the crowd?

2. Furthermore, in a culture where we historically hold technology near and dear to all that we do, how do we make a convincing case for the need to build a business based on openness, trust, and value delivered beyond the technical stack?

3. What does, or should, “Cognitive” actually mean to those who experience it?

We struggled with our answers to these questions. At best, we had a set of hypotheses we wanted to experiment and test on. We put our stake in the ground and got to work.

The fundamental premise behind our work in what we now call “Watson Health Cognitive Services” is pretty straightforward:

  • We have several Watson solutions focused in healthcare and life sciences;
  • These solutions are sold to clients via IBM’s massive sales network;
  • These solutions tend to address specific client pain points;
  • Clients tend to ask for “underlying technology” which can be used to address other pain points;
  • We have lots of “underlying technology” that make up those solutions.
  • What if we take these “underlying technology” and made them consumable as components which can be readily deployed and plugged in to existing and/or new solutions?
  • What if we can power up an entire generation of innovation with what we have to offer? Could that be a way for us to build our business based on the sense of openness and trust I described earlier?

We’ve made significant strides in the two years I spent with the team on this mission, and we’re just getting started. I cannot wait to witness when Watson Health Cognitive Services will be open for business, and I eagerly await with the Pager team on the other side of the aisle.

As with the other chapters of my IBM career, I cannot thank my team enough for their support and encouragement every step of the way — Tim Bouhour, my partner-in-crime, for the many long nights spent on our portfolio; Ryan Musch and Rebecca Buisan, our IBM “investors”, for the trust you placed in our team since the beginning of our journey.

Farewell, For Now

Farewells should be brief. We cannot dwell too much in the past, despite how good it has been. I’ll end with a quote in Richard Branson’s letter to Virgin America:

George Harrison once said, “All Things Must Pass.” This was the ride and love of a lifetime. I feel very lucky to have been on it with all of you.


My Somewhat Unconventional Analogy to “What’d Make a Great Product Manager?”

My Somewhat Unconventional Analogy to “What’d Make a Great Product Manager?”

I had just wrapped up another full-day onsite interview session at the RTP office this past Friday for IBM’s new cohort of future product managers. Exhausting, but I remain intensely optimistic as we attempt to change the culture of product management for this massive 100+ y.o. organization from inside out, one offer at a time. 1200 applications. Dozens of video interviews. 16 onsite fly-ins. Offers out the door in the coming weeks.

During the day (and the cocktail evening prior), we met a group of high energy, and well-qualified candidates of a diverse range of personalities and background. As we got to know one another over this time, I’ve been hit with questions of varying versions around “What’d make a great product manager?” Not my first time getting these questions. Without much hesitation, I fed our candidates with the typical answers we’d expect — “passion for our users”, “intense curiosity”, “ability to think broadly and in a highly detailed manner at the same time”, etc. However, it became more apparent to me that these metrics still leave plenty of room to this sense of ambiguity — ambiguity which we deal with, and have learned to embrace.

As I brooded over my disappointing response, I began to wonder how my colleagues thought about who they’d want to bring on to their team. Naturally, when we came up for air in the “command center” in between our interviews, I introduced the same question in their mind.

“What does a great product manager mean to you? No, I’m not talking about our established metrics/guidelines. What would make you seriously think about hiring or not hiring someone on your team?”


“Well…” a brave soul daringly took the lead.

This is where the conversation became very interesting. If our candidates can put on their invisibility cloaks and just sit in the room, they’d be surprised to find how starkly different the responses are from one another. I remember leaving the room thinking to myself: “How can we possibly articulate what a good candidate is if we barely know ourselves?”

Aquila – Standard of the Roman Legion

I don’t know how many of you studied Latin when you were growing up, but I grew up as a Latin kid (with a teacher and mentor one would dream of having). You see, as with learning any language, what you learn goes far beyond the language itself. You learn to appreciate the culture, the history, and everything else that comes with the language.

Shameless plug here — if you don’t know much about the Romans, look into it. You might be pleasantly surprised and/or fascinated by what you find. Here is a really awesome documentary on the Rise and Fall of the Roman Empire. For those of you who like Cliffs Notes version of everything, here’s a crash course. You’re probably not going to gain an appreciation for the Romans, but hey, we all start somewhere right?

So far, in this post, you’ve already seen a thing resembling an eagle (aquila) and an image of a person carrying an eagle standard (an aquilifer), and you might be wondering why I’m referencing these in this post. Well, here’s my attempt at drawing an analogy which made sense to me, and it all starts with the notion of the aquila and the function of the aquilifer in the Roman Legion.

An aquila, or “eagle”, is a prominent symbol for the Roman Legion. An aquilifer [= aquila (eagle) + fero (carry/bear)], or “standard bearer” is a legionary who carries the aquila. Each Legion is made up of 10 cohorts (~5000 men) and carries one aquila.

The aquila was extremely important to the Roman military, beyond merely being a symbol of a legion. A lost standard was considered an extremely grave occurrence, and the Roman military often went to great lengths to both protect a standard and to recover it if lost; for example, see the aftermath of the Battle of the Teutoburg Forest, where the Romans spent decades attempting to recover the lost standards of three legions.

Now, how is this at all relevant to product management?

As I toiled over the single-most important characteristic that I look for in a great product manager, I can’t help but make the connection to the function of an aquilifer in the Roman Legion. Let me explain why.

Given the significance of the aquila in a Legion, there is a natural importance placed upon the role of the aquilifer. However, this is not a game of “capture the flag” as you might expect. The aquilifer not only carries the weight of the Roman Legion on his shoulders, but also the initiative — the initiative to take his men to great victory, or great peril. The importance of the aquilifer was well accounted by none other than Julius Caesar in his De Bello Gallico IV.25, which I shall share below.

[25] Quod ubi Caesar animadvertit, naves longas, quarum et species erat barbaris inusitatior et motus ad usum expeditior, paulum removeri ab onerariis navibus et remis incitari et ad latus apertum hostium constitui atque inde fundis, sagittis, tormentis hostes propelli ac submoveri iussit; quae res magno usui nostris fuit. Nam et navium figura et remorum motu et inusitato genere tormentorum permoti barbari constiterunt ac paulum modo pedem rettulerunt. Atque nostris militibus cunctantibus, maxime propter altitudinem maris, qui X legionis aquilam gerebat, obtestatus deos, ut ea res legioni feliciter eveniret, ‘desilite’, inquit, ‘milites, nisi vultis aquilam hostibus prodere; ego certe meum rei publicae atque imperatori officium praestitero.’ Hoc cum voce magna dixisset, se ex navi proiecit atque in hostes aquilam ferre coepit. Tum nostri cohortati inter se, ne tantum dedecus admitteretur, universi ex navi desiluerunt. Hos item ex proximis primi navibus cum conspexissent, subsecuti hostibus adpropinquaverunt.

When Caesar observed this, he ordered the ships of war, the appearance of which was somewhat strange to the barbarians and the motion more ready for service, to be withdrawn a little from the transport vessels, and to be propelled by their oars, and be stationed toward the open flank of the enemy, and the enemy to be beaten off and driven away, with slings, arrows, and engines: which plan was of great service to our men; for the barbarians being startled by the form of our ships and the motions of our oars and the nature of our engines, which was strange to them, stopped, and shortly after retreated a little. And while our men were hesitating [whether they should advance to the shore], chiefly on account of the depth of the sea, he who carried the eagle of the tenth legion, after supplicating the gods that the matter might turn out favorably to the legion, exclaimed, “Leap, fellow soldiers, unless you wish to betray your eagle to the enemy. I, for my part, will perform my duty to the commonwealth and my general.” When he had said this with a loud voice, he leaped from the ship and proceeded to bear the eagle toward the enemy. Then our men, exhorting one another that so great a disgrace should not be incurred, all leaped from the ship. When those in the nearest vessels saw them, they speedily followed and approached the enemy.

So if you ask me the same question in the future, here’s my answer — someone who has the guts and the judgment to lead the charge and put a stake in the ground in the face of uncertainty; someone who takes the calculated risks necessary in order to help his/her team succeed, and at times, at the cost of his/her innate tendency for self-preservation.

Romanticized much? Indeed. But a worthwhile goal.

The Not-So-Few Confessions of a New Product Manager

It’s been roughly a year since I stepped into the Product Management role here in Watson Health. I recall looking up what “product management” meant during the first few weeks and had come across a wealth of literature on how others define product management and what makes a good product manager. While my experience so far falls somewhere in line with the books I’ve laid my hands on, articles I’ve bookmarked, and the discussions held on this very topic, I can’t help but point out some of my personal takes on this discipline. This is a post dedicated for such reflection.

Product Management as a Mindset

Product management as a discipline has been widely discussed through multiple platforms. Heck, you can even take a specialization on software product management on Coursera today. Given that, I won’t dwell too much on the “science” and “art” of product management. Rather, I want to emphasize the state of mind the comes with product management.

The mindset I speak of is one which I find incredibly hard to verbalize. There is an incessant need to question – the “how”, the “why”. You are on a mission to find answers, but prior to embarking of these quests, you must know what you are really asking for. Asking the right questions, and I’ve come to learn, is actually really hard.

The difficulty in this thought process isn’t in coming up with the right questions, but rather, understanding how the questions you ask relates to the hypotheses you want to test. As product managers, we’d often find ourselves overwhelmed with such hypotheses that make up the entirety of your business case. Prioritization becomes an every day battle.

One of my absolute reads on the Internet is Wait But Why by Tim Urban (and co). High five if you already love it. Check it out if you’re new to it – I swear it’ll bring more laughter and bliss into your life, or feel free to “Dislike” this post. Oh, I guess LinkedIn hasn’t implemented this feature yet, or probably never will. (But why?)

It’s worth pointing out that “being curious” and “being a great product manager” are not necessarily synonymous. Based on my experience, great product managers are almost always curious, but being curious does not make great product managers.

The Scientific Method

I was trained as a biomedical engineer and had spent several years in clinical research (drug design and delivery). Consequently, the concept of hypothesis generation and validation through experimentation is deeply ingrained in the way I think.

There is a very specific reason why I decided to use “hypothesis” in the product management context, as opposed to any other words (many of us are familiar with “writing requirements”). The reality of the world we, collectively, live in is that we have access to very limited information. As product managers, we are faced with the need to make key decisions with such limitations. Now, hypothetically, even in a perfect world where we do have access to all information (public and confidential), we will still find ourselves making a tradeoff between information and time. Sure, you can try all you want to get the “proper” amount of information to inform your decision, but by the time you operationalize your decision, you might find that the window of opportunity might’ve just passed by.

When you are hypothesis driven, naturally, you’d want to iterate. There is an absolute cost (that you, your team, your business) pay for throughout this iterative process, so in a world of limited resources, your job as a product manager is to prioritize what hypotheses you test and iterate upon. This is especially important, and the research experience taught me this lesson early on, and at a very high cost.

Imagine this: You’re going to spend 3 yrs of your life working on a cancer research project. You’ve got some idea on what you want to prove out, but naturally, each experiment you run for a hypothesis will cost you X amount of time, Y amount of lab resources, etc. This is especially prominent if you’re in a “wet lab”, where your research depends on the natural growth cycle of cells and other organics. You get the idea. We have finite amount of time; finite amount of resource; finite morale, patience, and conviction (on your team), dot dot dot, dot dot dot. You are part of this “value” maximizing function.

The Ups and Downs of Your Stakeholders

As a product manager, you are the CEO of your product.

You’ve probably heard this analogy being used plenty of times. Sure, it’s a nice stroke on our ego when they put it that way, and sure, there are some similarities between “being a product manager” and “being a CEO”. Depending on the nature of your product management culture, you’ll also note some stark differences between the two roles. That’s not what I’m going to focus on.

As the “CEO of your product”, you have a moral and fiduciary responsibility for your stakeholders – those inside your organization, and those outside. Customers/users aside, you are inherently accountable to both your team and your investors. If you’re a startup guy/gal, this is pretty easy to see through. You’ve got folks who are in the grind along your side day in and day out. You’ve got a vision, and you’re on a mission to carry it out with them. You’ve got some rich investors who’ve dumped cash into your dream. You’ve got to work your butt off to make sure that they get that 30X return that they look for.

Wait, but what if you work for a massive organization like IBM (where I work)? The same stakeholder ecosystem exists for you. You’ve got folks who are in the grind (with a bit more work-life balance) along your side day in and day out. You’ve got a vision (hopefully truly yours), and you’re on a mission (hopefully voluntarily and passionately) to carry it out with them. You’ve got some rich investors (your business / CEO / General Manager) who’ve dumped “cash” into your dream, and you’ve got to work your butt off to make sure that they get the ROI they look for. When you look at it that way, perhaps what you do isn’t at all that different from if you were to run your own startup.

This is the culture of product management where I work. If you find yourself in a culture where you find the line between product management and project management blurred, perhaps it’s time for you to challenge the business on how they should operate.

There’s much more to be said. More to come, depending on the reception (perceived usefulness) of this post.