Since its introduction, there has been wide-spread discontent about Fleets. Have a look at the hashtag #FleetsFeedback and you’ll see what I mean.

And then there’s this from someone who is reputed in the domain of business and strategy.

Despite the number of retweets and likes, I find this tweet by Alec somewhat disappointing. It’s easy to make fun of Twitter based on this trend but this observation is superficial. Simply put, this is not how product management works! The who’s who in Twitter would’ve clearly tracked the evolution of Stories and its applicability to Twitter. Twitter may have criticisms over its “shipping” velocity but it by no way considers the product’s or business’s priorities. Every year is different. 2020 seems to be about Fleets.

While I won’t proclaim Fleets to be the best thing since nutella on sliced bread, let’s analyze this a bit further.

What’s Fleets’ value proposition?

Twitter is clearly trying to position Fleets, just the way Stories is positioned. Of late, Twitter has become a news outlet of sorts. For better or worse, it’s become a ground for political commentary. This shift from more “serious” engagement to more personal and casual conversations is something that I guess Twitter is hoping it’ll offer to its 330 million users. The fleeting nature of Stories make it more attractive for users to share personal feelings and thoughts.

According to an article on Verge:

Twitter hopes the new feature will help reduce the pressure around tweeting by letting users express more casual thoughts and feelings while also concerning themselves less with saying something profound or racking up likes and retweets.

While I understand the value proposition of Fleets, my gut feeling says that this looks good only on paper. The questions that immediately pop up are:

1. Where do the current Twitter base share personal/casual thoughts and posts?

2. Do Twitter users also use other social media apps? What’s the overlap?

3. If Twitter users are already habituated (and have an audience) for their personal/casual thoughts on Instagram/Snapchat Stories, why would they switch over to Twitter?

4. Perhaps, Twitter can learn from how Instagram effectively ripped off Snapchat’s stories and grew engagement by X%. What are those lessons? Are they replicable?

Ultimately, products do jobs for us. Twitter needs to understand what it does for its users. If you ask me, I personally don’t feel Fleets offers anything novel to Twitter users in its current form.

What’s the business impact?

Let’s talk business now. Fleets is another format for displaying Twitter content. Currently, you can write a plain text, send a gif, create a poll…now you can create content in the form of a Fleet. If you disregard the (questionable?) value proposition, Fleets actually opens up several avenues on how key business metrics can be impacted!

Ad revenue
With content in Fleets, there will be opportunities for targeted ad content. I’m being captain obvious here. According to their Q3 2020 report, 86% of Twitter’s revenues comes from ads. So there are no surprises here on what is riding on Fleets. Perhaps, the costs per impressions on Fleets will be higher than the average promoted tweet given the larger real estate on the screen.

mDAUs
Monetizable daily active users is the user metric that Twitter reports. Currently it’s at 187 million and its growth is less than 10% QoQ. The introduction of Fleets could mean that users need to be signed into Twitter to view them. Something similar to Instagram’s stories. What this could mean is that the casual visitor on Twitter profiles or hashtags, would be required to sign up or log in to view Fleets.

Slide into more DMs
Direct messages improve user engagement and retention. Replying and reacting to Stories is old news for Snap and Instagram. This is something Twitter probably hopes to capitalize with Fleets. DMs will improve retention (stickyness). The more sticky the users are on Twitter, the more opportunities there are for advertisers to target these users. Here’s Lenny (brilliant Product guy, ex-Airbnb) comment on Fleets.

Live streaming
Fleets could integrate Periscope’s live streaming capabilities. Periscope was acquired by Twitter in 2015. I’ve personally not seen Twitter as a live streaming platform. The preferred platforms have always been Twitch, Youtube and Instagram. Although I don’t see this becoming a reality for Fleets, it might be something Twitter will consider for the future.

I’m sure there are a few more angles that I’ve missed.

Conclusion

By goal with this post was to analyze (albeit cursorily) the introduction of Fleets. While there is tremendous business opportunity, a lot hinges on Fleets’ adoption by users. Its adoption in turn hinges on the value proposition of Fleets, which in my opinion is lacking at the moment. It’s currently a bland me-too feature which doesn’t offer something different from Snap or Instagram. It will be exciting to see how Fleets evolves in the coming months. I’m sure the product team has something brewing there.

Will I use Fleets? Not right now as I reserve my more personal/casual posts for Instagram Stories.

Like any interview you undertake, preparation is important. Here are some of my learnings that I think anyone new or experienced at customer interviews might find useful.

Learnings

Segmentation


Before talking to the customer/user, it’s important to get as much context about who she is. You want your segmentation research to give you an idea on who she is, how long has she been using your product, how active is she and how much is she paying for it. This will help you make assumptions on what drives her to use (or not use) your product. 


Have a script ready


It’s always handy to have a script prepared on what questions you plan to ask the user. This not only helps you bring a structure to the interview but as you interview many users, a script ensures that the same research methodology is applied in the entire set of interviewees. 


Avoid leading questions

Leading questions would probably form an entire chapter in a book about doing good customer interviews. However, if I were to extract the gist of it, it could be simply put as - “Avoid questions that can be answered with a yes or a no”. Leading questions do not add value to the research process as you fail to understand factors influencing users’ decisions or their emotional state. The answers you seek in interviews should not be biased by the questions but rather you want customers to open up about their experiences. For example, if you ask a user - “Are you having problems with our product X?” The answer could be a curt ‘no’ or a ‘yes’. But if you frame the question as “Can you walk me through how you use our product X?” The latter helps pinpoint the journey of the user and the “problems” that you seek will be revealed in due course of time with follow-up questions. Refer to the next point below on the five whys. 


The five whys


This is a simple yet effective technique to get to the bottom of a problem. It was first conceived in the Toyota production facility for identifying bugs. In the interview setting, it is brutal and unrelenting when used in the right manner. The short version of how this is done is when the interviewer persistently quizzes the user with a “why?” and follows that with another “why?”. At times, insights are derived before the fifth why is asked but it’s the process that matters more. This could be an example of asking the five whys:

Me: You’ve been using our product X for 2 years now. Can you walk me through how you interact with feature Z.

User: I actually don’t use feature Z.

Me: Why don’t you use feature Z?

User: I don’t know, it looks complicated.

Me: Why do you think it is complicated? 

User: I visit the page and I see a lot of text that I don’t understand. 

Me: Alright, why do you feel that way? 

User: English is not my first language and I also prefer to see a tutorial video to understand how to use a new feature
.
…and the process continues but I hope you catch my drift.


Don’t listen to the user’s solutions


It’s easy to fall prey to what the user/customer says about your product. The caveat here is that the customer is not always right. It is imperative as an interviewer to understand what problem the user is facing rather than accepting the solution the user instructs you to build. This is a fairly common occurrence where users lay out feature-flows and solutions down to the tiniest details. But as a product manager, you are solving problems for an entire customer/user base, not just one person who gives her version of the solution. 


Record, record, record


Record your interviews in one way or the other. If it’s an interview that is happening over video call, then you can ask the user’s permission to record the session. Or else if you have a co-interviewer who can observe and take notes during the interview, that is another good option. If all else fails, you need to brush up on your note-taking abilities. You wouldn’t want to miss out on key insights during the interview process that you can revisit at a later time. 


When do you stop interviewing


This is quite a common question that comes up. Just how many customer interviews is enough? The unfortunate answer is that it’s never enough. But my general thumb rule is to interview as many people within a particular time period and you should stop interviewing when you see a pattern developing in your responses. In short, stop interviewing when you stop seeing variability for that set of customer interviews.

On a closing note, these learnings and observations have happened over a course of time and I hope you found them useful. While researching this topic on the interwebz to see other people’s opinions, I also came across a very useful chart on conducting interviews at the Product Tribe which is quite share-worthy.

Until my next post, happy interviewing!

Source: https://producttribe.com/product-management/customer-interviews-guide

One of the primary motivations for me to pick up 'The Hard Thing about Hard Things' is the essay titled 'Good Product Manager, Bad Product Manager'. This was first featured in the book and has been widely touted as a 101 reading for all aspiring product managers. And rightfully so. I had read that essay a couple of years ago and it outlines the qualities of good product managers and how most fall into the trap of certain bad habits. It's essentially a list of dos and don'ts. A good product manager makes a team a winning one, whereas a bad product manager creates negative value for the team. The essay can be read here.

But moving on to the book on the whole, it was an easy read. I suspect this would even be entertaining for a reader if s/he is not well versed with business jargon. Each chapter comprises of the choicest anecdotes from Ben's expansive career from Netscape to Loudcloud to Opsware to HP and finally a16z. All of these stories, if not relatable, will evoke a sense of empathy with Ben's narration. I love the honesty and the struggle behind each of the big decisions Ben, as an entrepreneur, had to make.

'The Hard Thing  About Hard Things' succeeds like no other business book because it embraces failures while instilling advice and leaving you with memorable takeaways. Sure, what you may face as a future entrepreneur may or may not mirror Ben's or Marc's (Andreessen) struggles but the learnings are timeless and many of them can be applied in different scenarios. For example, no matter what team you lead, your team members will have the base expectation of you not bullshitting them. Many team leads and CEOs fall prey to this. This is one of the basic principles that is hammered to the reader with many of the stories. Some of the other key lessons that Ben talks about is going against the grain of the executive management or board members. Important decisions often get swayed by group-think or risk-averseness. It's your job as a CEO/manager to champion the tough decisions especially when you have corroborating evidence of a positive hypothesis, whether data leads you that way or it's customer feedback or market research, what have you.

As you progress through the book, you will realize that Ben's narration pretty much covers the major events in the life cycle of a company. Some of those are:

• Working in a startup and scaling it

• Product - Market fit

• Fending off competition from incumbents

• Excelling at sales

• Knowing the true value of your company/product

• People management as your company scales

• Knowing when to go public with your company

• Knowing when to get acquired

One criticism that this book faces is that most of the stories predate the current millennial-tech-ecosystem. Okay that's not really a thing (or is it?). But I hope you get my drift. The companies mentioned in examples by Ben aren't glamorous but they're hardcore businesses which survived the 2000 dot-com bubble, made hundreds of millions of dollars and one even being valued at $1.6 billion dollars in the mid 2000s. If those aren't great benchmarks, I don't know what are. Just because a Snapchat may have a completely different model, doesn't mean that their teams don't struggle with sales or people problems. A lot of the learning in this book stems from principles of doing business and handling situations.

The Hard Thing About Hard Things is not an entrepreneur's playbook to success but it's a warning to that lot that...well...shit happens! And when you realize that you've been dealt a bad hand, Ben proves that there are still ways to maneuver through them and come out standing. It's a book to be re-read multiple times! 

I'm going to wrap this up by quoting some of my favorite lines from the book. There are many to choose from but these quotes were an instant home-run for me and they left me nodding profusely in agreement. 

"Note to self: It’s a good idea to ask, “What am I not doing?"

"Take care of the People, the Products and the Profits - In that order."

"If you're going to eat shit, don't nibble!"

"A healthy company culture encourages people to share bad news. A company that discusses its problems freely and openly can quickly solve them. A company that covers up its problems frustrates everyone involved."

"Having dogs at work and yoga aren't culture!"

All in all, pulse, is a very fluffy word to describe what I just wrote but I believe the best product managers have this as an unsaid trait. It comes naturally to the curious and the ambitious. Personally, I’ve been trying to better myself at getting a pulse of the aforementioned things. I try to read more, I listen to relevant podcasts and I avoid any blinders restricting my vision lest I miss out on anything. 

So…great, you’ve nailed your product-market fit, you’ve validated your ideas, you’ve prioritized your backlog…what next? 

The third important P of being a product manager is Project Execution. Notice, how I don’t say project management. How a product manager brings design and technology together is what constitutes execution to me. Project execution would certainly vary from company to company. In more established companies like an Amazon or Facebook, a product manager isn’t alone in execution. One works with technical product managers, program managers, engineering managers, tech/dev leads and so on. But if you’re in a seed-funded or series A funded startup, product managers end up playing a larger role in execution. The scope of responsibilities vary, but I’m going to talk from my own personal experience. 

• People — The success of project execution solely depends on your team. It is important for the entire team (designers, engineers, QA testers) to be on the same page. But hey, you’re a product manager. You have no authority over everyone else. This is where as a product manager, you need to play your ‘people skills’ cards well. I strongly believing that motivating the team before and after the project, irrespective of the size of the release, is key to having the team stick together. You show them impact, the potential of a product they’re building and how important each of their contributions are. A product manager must in no way take credit away from the team, after all they’re doing all the heavy lifting. Sure, you “conceptualized” the idea but make no mistake about it — your team will lose faith in you.

• Timelines — You will need to approximate timelines pre-development while sprint planning. You will need to get finer timelines from design and development. You will need to give out timelines with additional buffer, wherever necessary, to your stakeholders. Timelines are sacrosanct. There will definitely be times where you don’t meet these deadlines but it’s crucial to inform your stakeholders about any delay and possible alternative timelines.

• Development — If you’re a non-technical product manager, you would be solely reliant on your engineer leads or senior engineers. Invariably, engineers do come back to product managers with doubts, cases missed, cases where they’re block. It’s your role as a product manager to ensure that any doubts/blockers are swiftly resolved. You gain the respect of an engineer if you clear her blockers promptly.

• Testing — One of my strengths as a product manager is that I’m very hands-on with my product during development and testing. The more rigorous the testing, the fewer chances of your product failing in the user’s hands. Once the engineer(s) hand over the product to the QA team for testing, I step in between to do a pre-UAT (user acceptance test) where I try to ensure that the product is behaving as it should for the users’ major cases. I say ‘major cases’ because you are generally constrained for time. The pre-UAT testing phase significantly reduces the back-and-forth exchanges between QA and engineers. Once the QA team gives a sign off on product testing, I usually perform a UAT thoroughly to ensure that the product is ready to be shipped.

• Shipping — Here you have it, your feature/product moved from a staging test bed to your production servers. I prefer to ship out new releases on Tuesday, Wednesday, Thursdays or when the next day is not a holiday. That’s because in the slightest chance that there is a bug, you have the team available to quickly re-ship a bug-free version as soon as possible.

• Post-shipping — Is a product manager’s job done after shipping? Hell no. Sure you may have dusted your hands and got that awesome product released. While this doesn’t fall under the purview of ‘execution’, how else will you measure how successful it is? Are your users using the product as intended? Whether it’s a beta release or a full fledged roll-out, it is essential to choose the right metrics and have those metrics closely monitored either via data pulled from the database or analytics tools like Google Analytics or Mixpanel. A topic like measuring success metrics would require its own blog post.

So there we have it — Pulse and Project Execution, the two remaining Ps in what makes my three essential Ps of being a product manager. While I can’t cover everything with this 3Ps post because, let’s face it, product management is a fluid field, part science and part art. 

I would love any feedback on this post. Do write in at me@vcent.in if you would like to talk further about product management. 

Fascinating, non?

Traction starts off by emphasizing greatly on a method they call the 'Bullseye Framework'. True to its name, it is a process which involves narrowing down on that ONE channel which will give you the most traction initially. This may seem very intuitive but you'll be surprised how many companies get that wrong. In summary, the 'Bullseye Framework' requires you to brainstorm on all possible traction channels, rank them on the basis of potential, run quick tests for hypothesis testing and then finally focus on that identified channel.  As you progress through the book, you'll realize how central this process is for companies (as shown in the examples) in identifying their first channel.

With that as the crux of the book, the authors go on by enlisting 19 different traction channels that have worked for companies across industries. There is a dedicated chapter to each of those 19 traction channels. Some of the obvious traction channels mentioned are SEM, SEO, Display ads and Public Relations. Some of the not-so-obvious traction channels listed in the book are Engineering as Marketing, Community building and Viral Marketing (yup!). Each of those chapters outline the how-to, benefits and impact of the said traction channel. What adds further value are real world examples. One such example is about Mint, a website which helps users with managing finances. On starting up, the company had a goal of signing up 100,000 users in 6 months. By following the Bullseye Framework, Mint realized they could target personal blogs as their first traction channel. This led to 20,000 users signing up even before the official launch of their full-fledged product. Crazy, right? Once the company realized they were exhausting blogs and weren't seeing a spike in growth, they resorted to Public Relations as a channel. This eventually led the company to signing up 1 million users during their first 6 months. 

What I love about this book is that it appeals to both the layman as well as the seasoned marketer. Unlike many "management" books, Traction does not faff about. There's no jargon, no worldly business advice, no bullshit. The book stresses upon a simple framework, emphasizes on hustling hard by rigorously testing traction channels and repeating the process in case of failure. The book also talks about the importance of dividing your time between traction and product development.

Traction is a short read but I can see myself getting back to it whenever I have to ponder upon any of the traction channels mentioned here. If it were up to me, I'd prescribe this book as essential reading for all business school students because this is as real as it gets.

You can buy the book here.

Brimming with new found enthusiasm, I dashed off to a nearby salon. I had revived the long lost feeling of wanting to go bald. This feeling first overcame my rational-thinking about two years back. It was more about succumbing to peer pressure at that time because a couple of my close friends and I had made a pact to remove every strand of hair from our heads. What became of that pact? Well I chickened out. I had to, for I realized I actually had a lot going on and I just couldn’t let some foolish pact destroy me. Until that point of time, I was maintaining an untarnished reputation of a (deceptively) simple bloke; I was interning at a reputed company and something like a shiny bald head had the potential to raise eyebrows and who knows it could’ve well caused a furore in that conservative environment.

This time it was different. I couldn’t care less. I know I won’t be subjected to a before-and-after scrutiny by any acquaintance of mine, because quite frankly I know no one here. On that positive note and with a brimful cup of enthusiasm, I dashed off to a nearby salon.

I found the barber in a pensive mood. He probably hadn’t had a customer all day. With the ol’ wave-of-the-hand-in-front-of-the-face, I got his attention and the cutting of hair got underway. As opposed to how the biblical Samson felt about haircuts, I’ve always felt it was in a way, metaphorically speaking, self liberating as it injected new life into me while getting rid of excess baggage. This time though, I was going for full self-liberation!

I directed the barber to use the machine and shave off everything. Paying little attention to what I had said, he flexed his fingers and crackled his wrist joints and finally spoke, “It won’t look good on you, sir”. “But this is how I want it”, I demanded. Again, casually chewing his paan he proceeded to trim the sides of my head without paying any heed to what I had to say. I was flummoxed. My calm disposition prevented me from leaving the place promptly and I somehow consoled myself with the thoughts of telling him to trim it all off when he’d reach the top of my head.

The scissors slowly meandered around my head, cut a micrometer of hair with each stroke and paused. The barber would then take a moment to analyze his work and with an artistic gleam in his eye, he’d proceed to slash another couple of micrometers. What Monsieur Van Gogh (ha!) didn’t realize was that he spent close to twenty-five minutes only on the sides of my head. Maybe it was his intention to do so while slowly and tastefully culminating to the top or maybe he was just bored. That seems perfectly fine if you are a, dare I say, connoisseur and an appreciator of fine (hair-)art. I’m not and my plans of getting a brisk haircut were thwarted by this fool of a person. I had to put a stop to this madness. “The sides are quite short…that’s fine. Now cut the top as short as you’ve cut the sides.” That sure told him right?! He nodded in agreement but the moment I mentioned, “…use the machine”, he was taken aback and disapprovingly said, “It’ll be very short. It won’t look good. I’ll use the kenchi and give you a nice slope-cut”. At this point of time, I was convinced that he wasn’t going to be able to do what I asked. I gave up point blank and ended up getting just another haircut. I could smell victory in his faint humming. Bastard.

Somehow I can’t get over the barber’s unwillingness to use the machine and do as I wanted. Maybe it’s just me, but I suspect that he actually enjoys his job and that a machine-shave would probably have just destroyed the simple joys of doing everything by hand. He even took his own sweet time and I can only guess that he was savoring each stroke and each blissful sound of the ‘kenchi’ going ‘ka-chissh’.

Who knew that a stupid tale like this would have certain undertones suggesting something so essential in today’s world like job satisfaction?  Silly as it is, it’s made me realize that following the herd and landing up with something average is a big NO for me. So if you’ll please excuse me, I’ll go brainstorm my plans for 2009.