Attack with Numbers

CEO of the product?

2014-12-17T09:54:25-08:00

After publishing I love Product Management, I received this great question on Twitter:

@paulcothenet for example “responsible for right product/right time and all that entails” - this seems much wider than PM as I understand it
— Ben Pickering (@benpickering) December 7, 2014

When I transitioned to PM, I had no idea what I was doing (and neither did the people around me). So I started a frantic search to understand what the job was about. Good Product Manager, Bad Product Manager by Ben Horowitz was one of the first thing I read.

As I went trough it, I went through the following emotions in a very short amount of time:

“This job sounds awesome”
“This sounds pretty damn hard”
“There’s no way I can do all this” (to my defense, we didn’t even have marketing or PR at the time)

If you’re a junior PM, Horowitz’s description of the PM looks much broader than your job description. I’m sure there are plenty of new PMs that are as puzzled as I was, so I hope this can help.

tl;dr: #

As a junior Product Manager:

All this doesn’t apply to you (yet). It was written in a specific context and your organization and current role might not be up for it.
It’s still incredibly useful in helping you grow into your role and evaluate your organization.
Think “How can I become the CEO of the Product” rather than “I’m the CEO of the product”

A bit of context #

This document wasn’t written to be shared outside of Netscape. This was 1996 and people were not yet giving generic management advice on the internet. Horowitz wrote it while in Product Management at Netscape / AOL as a training document for his own team. I’d bet he didn’t expect it to be so widely circulated.
When he released it he expected that people (like me) would scrutinize it to no end, so he accompanied it with this word of caution:

“Warning: This document was written 15 years ago and is probably not relevant for today’s product managers. I present it here merely as an example of a useful training document.”

Of course, given the profile of the author, this warning has been largely ignored.

Why Good Product Manager, Bad Product Manager may not apply to you #

Back to @benpickering’s question, there are several things worth noting about Ben Horowitz’ doc:

It was written for a specific context and a specific team
It was written by someone who was in charge of that team and could make sure the reality of the job would match the job description
The Product Management job spans a wide spectrum of company sizes, product types, seniority and organizations.

Here are some scenarios where you shouldn’t read too much into it:

Reason #1: Your company is way more early stage than Netscape was in 1996. #

In 1996, Netscape was a public company. Your company may have just one product. As a consequence, the CEO of your product is the actual CEO.
In this situation:

do whatever you can to help ship the CEO’s vision. Take care of the details, write PRDs, prototype, collateral, documentation, do QA…
try to grow you role into the one described in GPMBPM
don’t ask for those extended responsibilities. Prove you can do them by doing them. A good CEO will recognize this and relinquish his role over time (unless he runs into the Product CEO paradox)

Reason #2: You’re starting in PM #

Your boss doesn’t expect you to do all this (just yet). In this situation, figure out what’s expected of you at that stage and thrive to grow into this ideal position.

As pointed out by Bubba Murarka in The Three Skills of a Great PM, starts by nailing Product Execution (i.e. Ship your first product) before worrying too much about Experimentation and Idea Validation

Reason #3: You’re not really doing Product Management #

You’re doing Project Management. This is not necessarily a bad thing. I did this for half of my last job and I loved it. In this situation, you need to:

Know what game you’re playing and how you’re being evaluated
Get to a point where you can discuss with your management if this is the ideal situation for your company and you.

Reason #4: It’s not clear what your “product” is #

When you think about it, you’re not quite sure you’re working on a “product”. There could be several reasons:

You’re starting in PM and your manager is getting you started with a subset of the problem, usually a small feature. That’s all fine, just make sure you know who’s owning the larger product and align with her strategy. Also make sure not to get stuck there too long and to grow into your role.
You’re actually doing Project Management

Reason #5: Your product organization is messed up (more than usual). #

Sales and marketing (or the CEO) calls all the shot and you’re just fighting fires. No one in product/engineering is talking to customers.
In this situation:

Figure out if you can fix it. Maybe your organization is just waiting for someone like you. Can you take the lead, talk to customers and figure out what they want?
If you’re actively prevented to talk to customers or if you’re told “we know better”, run away.

Why you should still apply it #

That said, that piece is still pretty damn fantastic. Despite the word of caution from its author, I think it’s still relevant today and worth reading at least once every month. Why?

It’s a great way to evaluate your organization #

If you’re an individual PM, this document is a great way to judge the quality of your product organization.

Is your organization thriving for the Good Product Manager items or do you hear too often the Bad Product Manager ones?
If you’re not responsible for right product / right time, who in your organization is? If you can’t identify that person, your company has a problem. Can you grow into that role?
If your manager thinks this doesn’t apply, are there clear expectations for your role?

As a junior PM at an established company, there’s only so much you can do to improve your organization. Problem is, when you get started, you don’t know what a good one looks like. If your organization looks too far away from the one described here, it’s probably not you, it’s them. Time to look for a better one.

It’s a great ideal to strive for #

As a junior PM, this might look overwhelming, but it’s close to the current definition of great product leaders. No one in their right mind expect you to be there on day one. But if you want to become great, this is where you need to go.

One thing that’s really hard about PM is that you need to sweat the small stuff (helping your team, fighting bugs, writing release notes and documentations) while never keeping your eyes of the prize. Reading Good Product Manager, Bad Product Manager regularly is a great way to avoid getting stuck at a local maximum.

One way this can f**k you up (and a reason why I put it that late in my PM 101 list is by making you try to do too much, on day one.
Don’t even try! (but take a look at Ken Norton’s checklist for that).

As a junior PM, I think it’s more useful to:

count the number of Good Product Manager boxes you check
strive to grow that number every quarter. Improve the quality of your work. Pick up additional responsibilities. Do more without asking or being asked.
measure your progress over time

CEO of the Product? #

A final word of caution: Perhaps the most well-known – and controversial – bit from GPMBPM is that the “Product Manager is the CEO of the Product”. There has been some lengthy discussions on Josh Elman’s piece about A Product Manager’s Job and its comments. I think it’s worth a few more clarifications.

As a junior PM, you will definitely not have authority over anything. You’ll have to influence without it. You’ll be owning things because people realize they wouldn’t happen without you. Not because you’ve been appointed to own them. Get a first few wins under your belt by doing everything it takes to ship your first product

As you’re starting, I’d say that a better to read this is “How can I become the CEO of the product? What do I need to do to get there?”. Like a CEO’s job, PM is a hard job. Don’t try to do too much at once but always strive to expand your scope. I hope this helped!

NOTE: There’s an expanded version of GPMBPM (attributed to David Weiden) floating out there that adds a few more point. Very worth reading too.

Thanks to Kevin, Léo and Francis for attempting to make sense of my ramblings and to Ben for letting me share his tweets. Cartoon by Leo Cullum for the New Yorker

Exercise your product muscles

2014-11-13T16:17:59-08:00

This post starts about soccer. But, don’t worry, in the end it’s about products. Apologies if you don’t care about soccer.

I’ve watched hundred of hours of soccer. I’ve probably seen hundred of players miss penalty kicks. Some of them from not too far away (I play goalkeeper). Yet, having seen all this doesn’t make me a better penalty shooter. In fact, I’m pretty sure I’d shoot like this:

I know that I should aim between the post. Avoiding the goalkeeper is probably a good idea too. Yet, that’s not what matters if you want to consistently score your penalty kicks.

What matters is your foot placement, the angle of your body, the position of your foot next to the ball, the spot where your other foot hits the ball, the spin you give to the ball… A lot of stuff you have no idea about if you’ve only watched soccer on TV.

Watching other people miss penalties doesn’t make me a better penalty shooter.

But I somehow had the delusion that this would be true for products. I don’t think I’m the only one. I often hear people complaining about how other people product ideas are stupid. Or how other people’s execution really sucks. Or how other people’s design are ugly and not intuitive.

I certainly did a lot of this myself. But then, when having to do my first product, for real, I shot like Sergio Ramos.

If you think about it, that’s not surprising. As Jason Fried says, “You’ll play like you practice. You’re not going to be sharp unless you practice being sharp.”

In product, what is practice? When you get your first PM assignment or start your first company, it’s not a practice shot. You’re in the Champions League. If you’re an engineer looking to practice, it’s relatively easy, you can code a side project. How do product people practice?

I would argue that you can use all those bad products out there and use them to improve.

Don’t stop at complaining they’re bad. That’s easy. Everyone can spot a lemon. That doesn’t mean you’re good at product.
Instead, try explaining in a few words what makes them suck
Could it be that they’re actually good, in a way?

Now think about what you would have done differently? Would you have built the product differently? Would you have built an altogether different product?
Why is it that there’s no good alternative? What is it that’s hard about it?

This also works with the good one. Go to Product Hunt every day, pick the top 3 products:

What makes them successful?
What did they get right?
How did the people behind this product think about this idea?

Exercise your product muscles. Don’t just criticize the decisions. Think (preferably in writing) about what you would have done. That way, when it’s your time to shoot, you’ll have some practice under your belt.

If you want to go even further, think about the person (or persons) that made this decision. This is Water by David Foster Wallace changed the way I look at other people (and I think it’s made me a better person). I would argue that forcing yourself to think differently about product will make you a better product person.

Think a bit more about that “stupid company adding a stupid iOS8 widget because it’s shiny and new, while their main feature is buggy”

What constraints were they under?
What other data points do they have that could explain their decision?
Who is their target user? Could it by any chance not be me?
Are they testing something? If so, what?

Your hypothesis might be completely wrong. This stupid product mistake may really well be the result of an overworked Product Manager not giving a shit about their customer.

But rather than making the lazy hypothesis, thinking repeatedly about the alternative explanation and how, in that same situation, you would have done better will make you a better product person.

When you get to shoot that penalty kick yourself, you’ll be better prepared.

I love Product Management

2014-11-01T17:39:35-07:00

Last week, I was asked by a student how I became a Product Manager and what was the right training to become one.

Tricky question. Because, as pointed out last week by Ellen Chisa in her great history of product management, there’s a lack of traditional resources on Product Management. Few great books, even fewer academic or training programs. Not much awareness among students.

This is a shame, because:

It’s the best job in the world (at least for me).
A lot of students and people starting their careers don’t even know this great job exists (I, for one, became a PM by accident)
A lot of time is spent reinventing the wheel.

Fortunately, people in the profession have stepped up to fill that void and write a cornucopia of great articles. It has helped me fantatiscally in my career I’ve been hoarding their best stuff like a squirrel for the last 4 years.
So here’s my collection, loosely organized. I hope it can benefit other people as much as it’s benefitted me.

All the credit goes to the great PMs and product leaders behind these lines. They’re part of the reason I love Product Management.

Level 0 - What is Product Management? #

A Product Manager’s Job - Josh Elman
Product Managers: Who are these ‘mini-CEOs’ and what do they do? - Ken Yeung
What exactly is a Product Manager? - Martin Eriksonn
What is Product Management? / Slideshare version - Sachin Rekhi
PM at Microsoft - Steven Sinofsky
Product Manager You Are… - Mat Balez
What Product Management is Not - Marty Cagan
Does the world need Product Managers any more - Multiple authors
Product Management vs. Product Marketing - Marty Cagan
Evolution of the Product Manager - Ellen Chisa
Use your Product Powers for Good - Bruce McCarthy

Level 1 - Is it really for you? #

How to hire a Product Manager - Kenneth Norton
The DNA of Product Management - Hunter Walk
The Dark Side of PM - Ellen Chisa
Do I need to be technical to be a PM - Ellen Chisa
Ode to a Non Technical Product Manager - Hunter Walk
Should nice people be Product Managers - Alex Pukinskis
3 Skillsets for PM Success - Kenton Kivetsu

Level 2 - Becoming a Product Manager #

How do I become a Product Manager? - Multiple authors
How I became a PM - Ellen Chisa
Do Product Managers really need a background in CS - Jackie Bavaro
Want to be a PM? Do a Project - Ellen Chisa
So You Want to Manage a Product - Rohini Viba
The 4 ways to break into Product Management - Jackie Bavaro
12 things Product Managers should do in their first 30 Days at a new company - Kenneth Norton
4 mistakes new Product Managers make - Matt Schnitt
Evolution of the Product Manager - Ellen Chisa
Starting and maintaining a career in Product Management - [Notes]
Cracking the PM Interview [Book]
PM Interview Questions - [Notes]

Level 3 - Building great products #

Inspired - How to Create Products Customers Love - Marty Cagan - [Book]
How to build great products - Slava Akhmechet
Make things as simple as possible but not simpler - Adam Nash
10 essential steps to create products that customer love - Laurence McCahill
The power of the perfect slice - Alastair Lee
Ten principles on the journey to building great products - Avid Larizadeh
Quality is not a tradeoff - Julie Zhuo
How to build products users love - Kevin Hale

Level 4 - Get out of the building #

The 4 steps to the Epiphany - Steve Blank - [Book]
Listen to customers - Kenneth Norton
Beginning Customer Development - Kevin Dewalt - [Ebook]
How do Customer Development and Product Management fit together - Cindy Alvarez
How to structure and get the most out of customer development interviews - Jason Evanish
The customer is always right. Except when they aren’t - Wade Foster
Your MVP is about discovery not product - Kevin Dewalt

Level 5 - Requirements! #

Painless functional specifications - Joel Spolsky
Inspired - How to Create Products Customers Love - Marty Cagan - [Book] - [Second Round]
Requirements are not - Marty Cagan
Feed the beast - Marty Cagan
The end of requirements - Marty Cagan

(I’ve always found this area a bit poor in resources. Any recommendations?)

Level 6 - Roadmaps, planning and prioritization! #

The seven deadly sins of product planning - Marty Cagan
Product strategy means saying no - Des Traynor
Product priorities start with strategic goals - Bruce McCarthy
You don’t need a product roadmap - David Heinemeier Hansson
The inconvenient truth about product - Marty Cagan
The opportunity backlog - Marty Cagan
The dirty dozen roadmap roadblocks - Bruce McCarthy
The pyramid model & what it means for PM focus - Kenton Kivetsu
How am I going to move my product forward today - Sachin Rekhi
Don’t publish a product roadmap - Colin Rand
Software Inventory - Joel Spolsky
Babe Ruth and feature lists - Kenneth Norton
What are the best ways to prioritize a list of product features - Ian McAllister
Before you plan your product roadmap - *Des Traynor
Rodmaps focus on vision benefits, not features - Bruce McCarthy
The one cost engineers and Product Managers don’t consider - Kris Gale
Guide to Product Planning: Three Feature Buckets - Adam Nash
Product hierarchy of needs - Tim Fletcher
Magical thinking and the zero-sum roadmap - Rich Mironov
Drop feature-based product roadmaps - Teresa Torres

Level 7 - Working with engineers (a.k.a Bringing the Donuts) #

The care and feeding of software engineers (or, why engineers are grumpy) - Nicholas C. Zakas
The ten project management commandments - * Slava Akhmechet*
5 things Product Managers wish they could tell developers - Brandon Satrom
How to work with PMs - Julie Zhuo
How to work with engineers - Julie Zhuo
How to work with software engineers - Kenneth Norton
The Iceberg Secret, revealed - Joel Spolsky
Leading cross-functional teams - Kenneth Norton
Engineers: So your PM sucks? Here’s how to fix it. - Ellen Chisa
Nerds, get the Product Management you deserve - Jeff Enderwick
The product manager’s lament - Eric Ries
Joel on Software - Joel Spolsky - [Book]
Peopleware - Tom DeMarco - [Book]
Team Geek - Brian Fitzpatrick - [Book]

Level 8 - UX and working with designers #

How to work with designers - Julie Zhuo

(I have more here but need to compile it a bit)

Level 9 - Giving and receiving feedback #

You won’t regret positive feedback - Zack Holman
Thirty percent feedback - Jason Freedman
How to run a design critique - Scott Berkun

Level 10 - Ship, Measure and Win #

Shipping is a feature - Steven Sinofsky
Great product leaders win games - Adam Nash
How to deliver more software projects on time - Mark Suster
Always be defining success - Jackie Bavaro
The only metric that matters - Josh Elman
The blind Product Manager - Paul Adams
Shipping beats perfection explained - Ben Kamens
Measure twice, cut once - Rick Klau
The lost art of the soft launch - Wade Foster
The Mythical Man-Month - Frederick Brooks - [Book]

Level 11 - Organizing a Product Management team #

Enter the Matrix - Organizing Product Management - Mark Tattersall
Product organizational structure - Marty Cagan
Good product team, bad product team - Marty Cagan
The best Product Management model - Marty Cagan

(I’ve done a lot of research on this subject but couldn’t find many good resources. Any recommendations?)

Level 12 - Managing Up #

Managing Up - Marty Cagan - [Notes]
Top hacks from a PM behind two of tech’s hottest products - Todd Jackson
Stakeholder Management - Marty Cagan
Court scribe or Hand of the King - Bruce McCarthy
Influence without authority - Sachin Rekhi
Management clichés that work - Steven Sinofsky
How to be persuasive - Jackie Bavaro
Bad Managers Talk, Good Managers Write - Walter Chen

Level 13 - Becoming great #

Good Product Manager, Bad Product Manager - Ben Horowitz (admit it, you were wondering when this one was gonna come?)
Be a great product leader - Adam Nash
Top 10 product leadership lessons - Adam Nash
What distinguishes the top 1% of Product Managers from the top 10?% - Ian McAllister
What makes someone a great Product Manager at Google? - Edward Ho
What innate traits do great internet product leaders share? - Chris Wetherell
Musings on Product Management - Mike Sukmanowsky
Hiring a great product leader - Sutha Kamal
What makes a great Product Manager? - Erik Torenberg
How a football coach taught me to product manage like a boss - Mike Su
How to hire a Product Manager - *Kenneth Norton * - [Second Round]

Level 14 - Moar! #

Ellen Chisa also mentions a few more.

Have more? You can comment and share your suggestions in this Hackpad.

You can also find this list:

Last note: Kenneth Norton, who sports some of the best articles in this list unfortunately lost his son Riley last week and is raising money for children with heart disease. Go donate if you like donuts.

The laws of shitty dashboards

2014-09-14T11:31:13-07:00

Disclosure: I have been responsible for building shitty dashboards. I personally made most of the errors below. I heretofore apologize to my users and pledge not to do it again. Hopefully, these anti-patterns can help PMs, designers and engineers reduce a bit the amount of time wasted building and looking at shitty dashboards.

Law #1: Most software dashboards are shitty #

When I say shitty, I’m not talking Google Image Search-bad (done vomiting yet?). I mean shitty in the sense of boring, poorly designed and devoid of any usefulness whatsoever.

Don’t believe me? Name 3 good software dashboards, right now

Found anything? Yeah, I guessed so. Yet, they’re everywhere. Any SaaS software you’re using probably has one, most likely as its home page.

You probably never look at it. It’s as if they weren’t there. (I call this dashboard-blindness). Thus, so, most software dashboards are shitty.

Side note: I’m talking trash about software here, but the law could be extended to all dashboards.

Take car dashboards for example. They use vast amount of real estate to display information that is useless 99% of the time. How often do you need to know the RPM on an automatic car? Can’t you just take that stupid dial out and put something useful instead?.

They also employ UX techniques that dates from a time where the only UI component you can use was a light bulb. If that red thing is critical, can’t you tell me right away what it means?

But since we can’t solve all of it, let’s focus on software.

Law #2: If it’s called “Dashboard”, it’s probably shitty #

If your collection of data widget is called “Dashboard” it probably doesn’t serve any purpose other than being there and moving. Which means it’s useless.

Corollary: “Let’s build a dashboard” equals “Let’s build a shitty dashboard” #

I don’t have the data to prove it, but I bet a lot of shitty dashboard started with the sentence “we need to add a dashboard”.

They are built without the users in mind because the product team has a bunch of numbers that they think could be useful. Or because the exec team somehow thinks “we need a dashboard”.

Law #3: If you don’t know what to take away from your dashboard, your users won’t #

I’ve been guilty of this one. Once, as a PM, I flat out answered the question “what is the use of your dashboard?” with a vapid “It tells the users what her numbers are”. Yeah…

It’s a classic fallacy. You have no idea what your users will decide based on the data you are showing them. But you somehow assume your users will know. Except you’re the one spending days and nights with the product and the data. If you (the PM or designer) doesn’t know what the data on the dashboard means and what to make of it, your users won’t either.

Corollary: A dashboard that does not take a stand is a shitty dashboard #

What the hell am I looking at? Does the designer has any idea what’s important here?

That’s the “let’s throw some spaghetti at the wall and see what sticks” approach. What you end up with is a giant mess on the floor.

Law #4: Not talking to users will result in a shitty dashboard #

The twin brother of Law #3. You don’t know if the dashboard is going to be useful. But you don’t talk to the users to figure it out. Or you just show it to them for a minute (with someone else’s data), never giving them a chance to figure out what the hell they could do with it if you gave it to them.

(You can substitute “product” for “dashboard” and law #4 still holds true)

Law #5: I don’t need no shitty control #

Also linked to law #3. Since you have no idea what anyone is going to do with your dashboard, why not throw more controls, to let the user figure it out?

The funny consequences of this one:

The user still doesn’t have the faintest idea of what he’s supposed to look at
You now offer combinations that are even more useless. My eternal gratitude to anyone who can tell me what to do with session duration at the hourly level. “People at 4:53AM on Monday stayed longer on the site than at 11:36AM”? So what?

Another other reason why stupid controls get added is because some user (most likely a data guy) asked for it. Unless you’re building a product for him, don’t listen to the data guy

Special mention to my favorite, the “last 14 days” option.

Law #6: Because it was useful in a Powerpoint doesn’t mean it’s useful on a dashboard #

Another fallacy is to think that because some graph is useful in a quarterly Powerpoint it will be useful to look at every day. Surprise: quarterly numbers don’t change that much day-to-day. Although it’s useful, it’s also incredibly boring.

Law #7: Because it moves doesn’t mean it’s not shitty #

Dashboard hell is paved with last 30 days daily numbers.

Can you think of a single application where that timeframe / granularity is actually useful? Most KPIs (traffic, revenue) are too volatile on a daily basis to be useful. Yet “last 30 days daily” is more or less the default option.

The reason are pretty easy to understand:
The numbers will move. If the users comes back tomorrow, there will be a different number.

Excitement!

Dopamine rush!

Then, best scenario: nothing. Because whatever that daily number tells you, you don’t know what to make of it.

Worse case scenario: a bad decision taken with non-statistically significant data.

Yes, 30-day daily graphs look way better than a single KPI with a trend indication. But they’re a lazy option.

Corollary: No one needs real-time #

Or near real-time. Or whatever you call it.

Real-time is the über version of #6. More dopamine, no actionable data whatsoever.

Law #8: You probably don’t need a dashboard #

If you can’t think of a reason (besides “they can look at their number”) why your users would use your dashboard, then you don’t need a shitty dashboard.

If your data is only useful on a monthly basis but doesn’t move much in between, maybe you don’t need a shitty dashboard. Send your numbers by email the end of the month instead. Sure, you can still build a shitty dashboard, but don’t complain that no one looks at it.

Nest does this pretty well. They send you your monthly usage numbers every month, yet you can’t find that info on the site. You wouldn’t look at it if you had it, would you?

Yes, back-end applications need ways to show their users that they’re working. I guess that’s the reason behind Stripe’s (otherwise pleasantly understated) dashboard:

Just ask yourself if a dashboard is the best way to achieve this. If something’s going awry (or well), shouldn’t you send me an email or text instead?

There are already a lot of shitty dashboards out there. Please save the planet, don’t create more.

Think I’m biased and could think about 3 good dashboards without looking? Tell me so on twitter!

A social media diet for the social media reticent co-founder

2014-08-27T14:03:12-07:00

My friend and co-founder @anselmelevan is not very active on Twitter. I think he doesn’t see the benefits of the platform and still thinks it’s something where people talk about what they’re eating.
On my end, I’ve been on Twitter since 2008 and still think it is one of the best things ever. I also think that it can be a great customer discovery channel for our company, MadKudu.

So I’m trying a 30-day pass/fail experiment to see if I can get him:

to enjoy the platform
a decent following

I could have sent him an email, but I’m pretty sure there might be other cofounders (or VP Marketing) out there with a similar issue. So, I’ve decided to over-share this.

We’re starting at 19 tweets, 27 following and 33 followers. Let’s see where this can go. I’ll probably amend this as the experiment progress.

Base rules #

Rule #1: Make your twitter feed interesting for you. #

If your feed sucks, you’re not going to want to use twitter.

Rule #2: Be natural. #

Tweet about stuff you care about. If you try to hide behind a persona it will get boring. See rule #1

Rule #3: Don’t just retweet the corporate account tweets. #

That’s just plain boring. Why would I follow the CEO if I’m already following the corporate account? Except the guy behind the other account actually engages with me.

Rule #4: Engage with people #

Twitter can be great as a content feed, but I’ve had my best experiences when I was able to engage with people on a consistent basis. It’s a great place to test ideas, ask for help or simply be useful. Its main advantage is not having any of the conventions of email.
(Note: Accounts that are just one-way publishing platforms are just plain boring. Unfollow them)

Rule #5: Persevere. #

Twitter can be a vapid place (live-tweets of the VMAs, stupid hashtags). It can also be a fascinating place where you see things you won’t see anywhere else (#Ferguson)

Daily regimen #

Tweet two interesting articles a day. #

Whenever you read something cool, post it to Twitter.
Don’t use (only) the article title in the tweet. Make it personal.
If the author of the article is on twitter, mention them in the tweet

Follow 5 new persons a day #

Make it an habit of following 5 new people of day. Don’t worry about following too many people. Just unfollow when someone starts not being relevant.

Engage with one tweet per day #

When you see an interesting link or article, engage with the author. At worst, do a simple retweet. At best, ask a question or add something to the conversation.

Ask openly for something once per week #

Have a passing question to which you don’t know the answer? Try asking openly on Twitter once a week. You might be surprised.

The goal here is to spend less than 10 minutes per day. Don’t spend more for now. I need you somewhere else ;-)

Other tips to add?
Reach out on Twitter:

@paulcothenet

@anselmelevan

Share this on Twitter

The day Amazon read my mind

2014-08-21T17:40:24-07:00

This mind reading story started in a banal way. I forgot my Kindle in the airplane seat pocket. Banal because I’m sure that happens all the time (it just hides in that stupid pocket) and because it was my third time.

But this time I did not get it back. Air Canada never found it. Good news: no one else seemed to find it either. I waited a couple days to see if anyone would buy a cornucopia of trashy fiction with my Kindle. Nope.

Anyway, I unlinked it from my account and was now in the market for a new Kindle. The last Paperwhite model was 9 months old. And there’s one lesson Steve Jobs told me. Never buy any Apple products 9 months after the previous launch. You’ll hate yourself in 3 months.
Amazon’s previous releases had followed a similar pattern. And the latest rumors were hinting at a March release. So I decided to wait a bit.

6 months passed. March flew by. Nothing. (We’re still waiting by the way)

At this point, I started to question even buying a new Kindle anymore. Paper books were not that bad after all (well, except when you fall asleep reading. Not losing your page when falling asleep is the biggest unsung advantages of e-readers). Do I even needed a Kindle anyway? Wasn’t buying a new one a proof of my addiction to consumerism? Was my reckless purchasing habits funding the death of bookstores, newspapers and dolphins? I had a few books left on my account, but I could still read them somewhere else after all. So I postponed even more.

Then, one day, in an episode of distracted web browsing, I head to Amazon.com. And there it is. Front page. In the million-dollar div container. The one reserved for bad tablets and Bezos-penned letters.

A Kindle Paperwhite.

Not a new version mind you. But one with a shocking sticker next to it.

$75 off.

I blink. I check my eyesight a couple time. Afraid it is going to go away, I add it to my cart the next second.
I’m not dreaming: $48 for a Paperwhite, tax included. I one-click order faster than it takes to say “states sales tax”.
The entire thing took less than two minutes. No one I’ve met ever saw that same offer (a few other people on the internet did)

Amazon has made advanced marketing tactiques quite mundane in the last decade but I found this one mind-blowing.
Consider the feat: I’m the opposite of an impulse buyer. I compare, I double-check, I double guess myself. All the time. And I’ve worked in predictive marketing and product recommendations for the last 4 years. I thought I had seen it all.

Of course, when you think about it, I left a few traces. Heavy user that stops purchasing, then inactivate a device. Search the site for Kindles several times. Look up on the web for the next release (not sure if they caught that one. That would be impressive). But even then, the pattern of who saw this ad doesn’t seem obvious.

Plus, it’s a risky move. Get a discount like this to the wrong user and you’re just cannibalizing your already razor-thin margin. (Given the number of Kindle books I’ve purchased since then, I’m sure my purchase has been a net positive for them.)

In any case, targeted discounting is about as advanced as it gets in predictive / lifecycle marketing. I’d like to know if it’s something they’re experimenting with on a large scale. Hit me up on twitter (@paulcothenet if you’ve received a similar offer or if you know more about it.

Thank you AgilOne

2014-07-11T15:06:05-07:00

“I know that, right now, you have no idea what we’re doing. But I’m pretty sure you’ll figure it out”

The day was December 16, 2010. I was meeting Omer Artun for the first time, in a completely empty office in Los Gatos. The company was called Agilone (still with a lower case o).
I was one day from graduating and three days from flying back to France for Christmas. I really wanted to stay in the US for my first job, but pretty much all my tentatives had failed so far.
I had not yet convinced myself that this was it. So I still had my car, my apartment, a hundred or so CDs and no plans yet to get rid of them.

At this point, there were a lot of things I was not sure of:

I was not quite sure about this “Analytics Associate” job. It was a client service position in “predictive marketing”, while I had just spent the past 2 years studying how to keep a nuclear reactor from exploding.
I wasn’t quite sure about the company either. It certainly didn’t look like your usual start-up, with its consulting past and east coast roots.
I definitely wasn’t sure about the location. Downtown Los Gatos seemed like an odd location and I did not really want to move or endure a 2 hours commute. And the office at the time was, well…

I was only sure of three things:

My friends Francis and Ben seemed to be having the times of their lives
Omer and Anselme seemed like pretty amazing folks
They had a vision and clients to back it up
I really wanted to stay in Silicon Valley for a while (Well, four things).

I really don’t know what would have happened if I had to make the hour-long drive back home without a firm offer. But I never got a chance to hesitate, because Omer printed me a contract on the spot, taking Ben’s old contract and simply changing the name on it.

“I know that, right now, you have no idea what we’re doing. But I’m pretty sure you’ll figure it out”

This sealed it. And I’m so glad it did.

Teşekkür ederim #

Fast-forward almost 4 years later:

I’ve spent 4 years working with fantastic people.
I’ve seen AgilOne grow from 25 to 125 people, go through series A, B and C, and from o to O.
I’ve seen AgilOne going from “What do you do exactly, again?” to “How do you compare to other in your fields?” (in a field that did not exist 4 years ago).
I’ve worn so many hats, caps, helmets that I will never worry too much about a “job description” anymore.
Probably learned more than I would have had in 40 years elsewhere.
Did I mention the fantastic people?

Omer, there is no words to describe how grateful to you for giving me this chance 4 years ago and trusting me the rest of the way. AgilOne is a fantastic company, full of amazing people and I’m certain you guys will accomplish great things.

Francis, Erik, Louis, Thibault, Kevin, Morgane, Josephine & Ebru, thanks for being amazing. I now have a lot more friends that are not coworkers.

Carrie, Ergin, Michael, Hubert, Brian, Ergin, Vlad, Sean, Ozer, Sridhar, Olivia, Hac, Jonathan, Sten-Erik, Fouad, Nabil, Gözde and everyone else I’m stupidly forgetting right now, thanks for supporting me (in all meanings of the word) this entire time. Thanks for being the most motivated, smartest bunch I’ve ever worked with. Keep it up!

And of course, thanks Anselme. But this one is just getting started.

For real feedback, use real data

2014-02-17T22:21:35-08:00

This is the first (of an hopefully long series) of articles on my day hobby, Product Management.
In this first installment, I discuss why, when working on a data product, you need real data to get real feedback

So, you’re building a data product.
Could be a personalization engine, a business dashboard or a clustering algorithm (among some real-life examples). Something that deals with data and/or numbers. Big or small, doesn’t really matter.

You’ve made your initial assumptions, talked to users and validated your problem. You have an idea for a solution and need to validate it. Your next step is to build a prototype, show it to users and see if they’re willing to pay for it.

The catch with data product: if you want really actionable feedback from your potential users, you need to use their own data. You can get some bits of feedback from a fake/generic data prototype but most likely you will fall into one these two traps:

False positives. Your users seem to like what they’re seeing. “Oh yeah, that’s really cool, can we have it?”. You go on and spend months building the actual product. After weeks of work, you ship the actual product to the users. They like the wireframes, they’ll surely like it. Instead, you start getting feedback like “actually, I’m only interested in half of this data, can we filter by X?”. Or worse “of course there is always going to be a customer with 100% open rate, what a stupid metric”. Or “that’s some nice trivia but what do I do with it?”.
Oops, you just wasted some valuable engineering time on an un-validated solution.

False negatives. Your users are indifferent to what you’re showing them. You might as well be showing them a chart of your weight compared to the GDP of Mauritania. “Yeah, nice chart. What else do you have?”. Doesn’t seem promising, you move on. And waste a possibly great product opportunity. I’ve seen users previously indifferent to a generic analysis completely light up once the number on the screen were theirs.

In both cases, there is something that clicks only once the user sees the prototype with their own data. After all, the value of a data product is mostly in the data (doh!). If you’re validating only the way the data will look or how the user will interact with it, you’re missing the main point. Only once they see the results with their own data will users start giving you useful feedback.

It will obviously require you some extra effort (development-wise + working around the Catch-22 of convincing the user to give you their data in the first place), but if you’re testing a data product with users, go feed your prototype with some real numbers.

Update: Marty Cagan, author of the great Product Management bible, Inspired, wrote about something the same subject in his article Flavors of prototype

How I lost my edge

2014-01-22T22:58:09-08:00

“You don’t know what you really want”

I didn’t ever think I would be able put a date on it. I was secretly hoping it would never happen. But I have to come to the truth. I’ve lost my edge.

It starts with the realization that it is something that actually happens to people.
As a kid, you realize that old people have not always been old. You make yourself the promise that you’ll never grow old.
As a young adult, you stumble into a copy of Trout Mask Replica in your dad’s vinyl collection and realize he hasn’t been listening to FM radio their whole life. You make yourself the promise that, this time, you won’t let it happen to you.

And then, of course, it does happen to you.

You go from doing monthly compilations of your favorite B-sides to making a playlist out of Rolling Stone’s year-end list.
18 of your top 20 bands last year were already around 10 years ago.
You only see movies after they’ve been Oscar-nominated.
You only buy books that have won some kind of prize (or were written more than 20 years ago).
The only albums you buy are vinyls of your favorite album from the last decade.
People still ask you for advice but you have absolutely no idea what to tell them anymore.
You start listening to the same songs over and over again (hello, cowgirl!).

Surprisingly, few people will tell you the real reason for this change. Some will tell you that the new stuff is just not that good anymore, which is bullshit.
The only real explanation is that staying on the edge takes time. Time to listen, read and compare all that stuff. And you just somehow happen to have less of it than you used to.

It’s a bit frustrating for sure. Like realizing that you can’t eat like you used to. But do you really need to eat two pizzas by yourself anyway?

There’s one thing I’m excited about though: the next phase.
After spending years looking down your tastes because they’re too mainstream, I can’t wait to look them down because they’re too new.
I’m sure I’ll be a great old schmuck.

Dear Journalism,

2014-01-13T21:36:42-08:00

Here’s to 2013 #

A Life-or-Death Situation, Robin Marantz Henig, New York Times
How the beliefs and convictions of a proponent of the “right to die” collides with her husband debilitating bike accident. Indispensable.

Bread and Women, Adam Gopnik, New Yorker
A beautiful glimpse into bread. Must-read if you know someone French.

Join Wall Street, Save the World, Dylan Matthews, Washington Post
Beyond, the witty title, the story of people revisiting how to help people meaningfully.

How James Turrel Knocked the Art World Off Its Feet, Leslye Davis, New York Times
The most breathtaking art expo I’ve seen (ever?) and the article that made me want to see it

Slow Ideas, Atul Gawande, New Yorker
For a change-obsessed Silicon Valley, a reminder of what it sometimes takes for important process to spread.

19: The True Story of the Yarnell Fire, Kyle Dickman, Outside
This year’s Snow Fall, without the smoke and mirrors. Well, with some smoke.

Into the Wildfire, Paul Tullis, New York Times
The counter-intuitive science and management of forest fires.

Change the World, George Packer, New Yorker
A look at Silicon’s Valley social changes and foray into politics (answers and follow-up worth reading too)

Survivorship Bias, David McRaney, You Are Not So Smart
What do the Department of War Maths, diets and superstar CEOs have in common?

How Not To Die, Jonathan Rauch, The Atlantic
Another dive into the dark world of unwanted medical treatment and how low-tech innovation can play a role

The Extraordinary Science of Addictive Junk Food, Michael Moss, New York Times

Inside the Battle of Hoth: The Empire Strikes Out, Spencer Ackerman, Wired
An hilarious tactical analysis of Darth Vader’s stupid strategy during the Battle of Hoth

A Pickpocket’s Tale, Adam Green, New Yorker

Oldies #

Federer as Religious Experience, David Foster Wallace, New York Times
If you enjoy tennis, you have to read this.

I do not fear death, Roger Ebert, Salon
Roger Ebert: The Essential Man, Chris Jones, Esquire

Achieving Your Childhood Dream, Randy Pausch

Not on this list #

Any of the 20 articles I’ve read this past year about how and why the French are unhappy.