Signal vs NoiseWhen you're deep in the trenches of a startup, a common dilemma always comes up: should you focus on improving metrics at the top or bottom of the user funnel? I was reminded of a stellar talk by Josh Elman that tackled this very issue, specifically in LinkedIn's case (unfortunately, that video is no longer available on YouTube).

Now, I’m a fan of paying attention to the bottom of the funnel first, especially in the early days. Why? Because those users who managed to get to the end of the funnel are the real MVPs! They stuck with your imperfect, buggy product and somehow found value in it. Optimizing for these heroes can offer real insights. You tweak the experience for them, learn what makes them tick, and then use that intel to attract more people who are similar, or "lookalikes."

But here's a curveball: What if you could identify users who are likely to reach the end of the funnel from the get-go? Think about Facebook’s "7 friends in the first 10 days" metric. They zeroed in on a behavior that almost guaranteed long-term engagement.

So who are these golden users for Wingman? We found that it’s those who actively search for a specific flight prediction market instead of picking from what's displayed on our homepage. This shows they have a clear intent, and are not just casually browsing. They're signaling from the get-go that they're likely to go deep into the funnel.

Instead of getting stuck in the endless debate of top vs. bottom of the funnel, consider identifying a specific cohort that shows their intention right from the early steps, like searching for a specific flight. Focus on them, and you might just find your own "7 friends in 10 days" golden metric. ?

Don't Ignore Load Times: Lesson LearnedToday I want to chat about something we often overlook but can make or break the user experience: loading times. ??

I was going through some user session recordings and noticed something weird. About 2/3 of our users were bouncing off the page right after they searched for a specific flight to make a prediction on. At first, I thought it was a glitch in the recording.

To double-check, I turned to Google Analytics data, which we export to BigQuery. Easier for slicing and dicing, you know? And, oh boy, it wasn’t a bug—users really were abandoning the search.

Long story short, I found that some pages took a whopping 25 seconds to load! I mean, who's gonna wait that long, especially on a mobile phone? More than 90% of our users access Wingman on mobile, so this was a big deal.

Here's where it gets interesting. While I experienced the issue, my colleague didn’t. After digging deep, we found the root cause: we use Google Cloud Platform’s Compute Engine to run our machine learning model for flight delay predictions. GCP kills the machine after a period of inactivity, and booting a new one takes time—like 20 seconds. Since we don't have many new flight markets created these days, the machine would often be inactive, leading to slow load times for most users.

TL;DR: Always measure and monitor your load times. You never know what hidden issues you might uncover that could be sabotaging the user experience

Growing the PieI've been getting a common question from a couple of you: "Why are you sharing all of this? Wouldn't your growth hacks become less effective if everyone knew about them?" ?

Well, I wanted to address this head-on. First and foremost, I believe we're still in the early days of the web3 market. Honestly, any notion of "competition" seems almost irrelevant. Right now, every team, product, and company is playing a role in growing the overall pie. If sharing our experiences can help even just one other team, then we're all winning together.

Secondly, sharing helps me extend my network of web3 builders. It opens doors for exchanging ideas, lessons, and even some "aha" moments. Back in the early stages of mobile apps development, having a network like this was a goldmine for our team. It’s no different now with web3.

Last but definitely not least, writing these posts helps me think more deeply about what we’re doing. It lets me internalize our journey, making me more aware of the steps we're taking. I strongly believe that living life more consciously isn't just some self-help mantra; it's crucial for the growth of individuals and teams.

I hope this clears things up. And hey, if you find these posts helpful, let's keep growing the pie together! ?

Twitter Traffic Tracking: The Mystery Solved

We recently faced an intriguing issue: a significant discrepancy between Twitter ad clicks and the numbers reported in Google Analytics. Our initial thought? "Ah, the infamous Twitter bots." ?

Before jumping to conclusions, we took a page out of a classic math problem where you need to distinguish fake coins from real ones. The algorithm often used in the problem involves dividing the coins into different groups and comparing their weights to isolate the fakes. Similarly, we divided our campaigns into subsets to isolate the ones causing the discrepancy.

After employing this "divide and compare" strategy, it turns out that one of our campaigns aligned perfectly with Google Analytics data, while another didn't. The difference? We used Bit.ly links for one and not the other.

Upon closer examination—check the screenshot in the comments for details—we discovered encoding issues in our UTM parameters ('%3F' instead of '?'). This led Google Analytics to categorize the traffic as "direct," skewing our attribution models.

To resolve this, we implemented a URL shortener across all campaigns, and the issue was fixed as expected.

Key Takeaway: Before drawing conclusions, especially when it comes to data discrepancies, it's crucial to investigate further. Just like solving the fake coin problem, divide your data and compare to pinpoint the issue. Validate your hypothesis with evidence that both supports and challenges it. This way, you'll arrive at an accurate understanding rather than a premature judgment.

KISS - Keeping It SimpleFollowing up on the BJ Fogg's model I mentioned (yep, the Motivation, Ability, and Prompt thing), let’s dive into how we've been working to make Wingman user-friendly.

Now, if you've been keeping up with my posts, you'd know there's a catch with Wingman in some places, like the US and UK. Yep, I mentioned this in the the Idea Maze post. Our initial brainwave? Pop up a disclaimer when users tried accessing the app from these spots. Sounds smart, right?

But here's the twist: By doing this, we were pretty much left in the dark. Users from these regions either had to mess around with a testnet version or just bounce. So, zero useful feedback for us.

So we tweaked things. To get those juicy insights (but still play it cool with compliance), we pushed the Disclaimer further down the user journey. It only pops up when someone's about to make their first prediction. So we get to see how users vibe with the product, gather feedback, and yep, still keep things legit.

I know, I know. You're probably thinking, "Why didn't you do that from the get-go?" Hey, we're all about learning and evolving here! ?

In short, let users dip their toes in the water, even if they can't dive right in. And funny enough, this ties in with Apple Human Interface Guidelines. But that's a story for another post. Stay tuned!

Telegram

web3 Growth Hacking

Idea Maze or RTFM Yesterday, Balaji Srinivasan brought attention to his 'Idea Maze' essay, an essential read that every startup founder should consider. In essence, the idea maze is a bird's eye view of the path a startup must follow. It's not just about…

? Frameworks Over Hacks

One of the foundational thinking frameworks I swear by is the BJ Fogg's Behavior Model. If you aren’t familiar, it states that for any behavior to manifest, three critical elements must converge simultaneously: Motivation, Ability, and a Prompt. When a behavior does not occur, at least one of those three elements is missing.

Now, why does this matter for startups or any product team? Simply put, it's an incredibly insightful lens through which to view user behavior. If a user isn’t engaging in a desired action within your product, there's a high probability that one of these three elements is amiss. Here's a cool twist—you can even make up for a lack of one element with the others. Low motivation? Make the action easier, and boom, problem solved.

But more broadly, I'm a huge advocate for using frameworks to guide our thinking and decision-making. Why? Because while growth hacks or specific tactics may provide short-term spikes, frameworks empower us with a structured way to think, adapt, and innovate consistently. They allow us to assimilate lessons from various domains, be it another product's successes or failures, and apply them in our unique contexts.

In future posts, I'll spill the beans on some of the hits and misses we've had using this model in Wingman ?

BenchmarkingBenchmarking is not just a tool; it's a revelation. A good friend of mine often says, 'Information appears when you compare,' and I can't agree more. In the world of web3, where we are building and innovating at a breakneck pace, understanding where we stand is vital. It's not about competition; it's about learning, improving, and growing together.

At this early stage of the market, our focus must be on growing the market itself, not merely competing within it. We're all part of a rising tide that can lift all boats.

Here's a snapshot from Wingman that I believe many web3 founders may find interesting. Our current conversion rate from visiting the app to connecting the wallet is about 2.2%. This simple number, when put in context, can be a mirror reflecting our strengths and areas for improvement.

Are you tracking similar metrics? I'd love to hear from fellow builders in the community. Let's compare, let's learn, and let's make web3 a more transparent and collaborative space. Share your data in comments if you are comfortable, and let's grow together!

From Simplicity to ComplexityBuilding a product can be a dizzying journey through complexity, but there's a systems law that serves as a grounding principle: All complex systems that work evolved from simpler systems that worked. Complex systems designed from scratch will never work in the real world, since they haven’t been subject to environmental selection forces while being designed. If you aspire to build a complex system, start with simplicity and refine over time.

In the rush to innovate, it's tempting to analyze competitors' products in their current, advanced state. But attempting to improve on all of their features can be a futile endeavor. What's valuable is peering back into the past to uncover the initial, more straightforward versions of those products.

When we were building Wingman, we didn't just try to outdo our competitors' current capabilities; we took the time to explore the Wayback Machine, product launch videos, and founder interviews to understand their evolution. This exploration of simpler systems offered some insights into what worked initially and how it could be evolved.

Regardless, do not forget the law and keep it simple at the start, then refine according to both quantitative and qualitative feedback from your users.

Embracing EmbarrassmentLaunching a product can be a nerve-wracking experience, filled with uncertainties and what-ifs. Reid Hoffman famously captured this sentiment when he said, "If you're not embarrassed by the first version of your product, you've launched too late."

During our recent team retrospective, some members expressed shame over our initial version, lamenting that many issues could have been fixed if we had only waited a bit longer. It's a natural feeling to have, but I reminded the team about Hoffman's saying. I intentionally spearheaded our launch to start receiving feedback from real users. Why? Because nothing sharpens your focus like real-world interaction.

Many team members agreed that the launch significantly honed our efforts. Interestingly, we found that 30% of what we had built wasn't even used by our customers. It was a valuable lesson in prioritizing what truly matters.

So, I guess, the lesson learned is: Don't be afraid to launch early, as long as your product implements the key use case. Embrace the embarrassment. It may feel uncomfortable at first, but it can be the catalyst for growth and refinement that your product needs.

P.S. Replaying sessions with user's struggles with some features is sooo painful ?

The Power of KnownsBuilding a product on the web has its many advantages, and one standout benefit is the ease with which you can set up and run A/B experiments. These experiments are crucial in optimizing user experience and improving conversion rates. But what happens when you're faced with a choice between what's trendy and what's familiar? Let me share a recent experiment we ran at Wingman.

We use Google Optimizer for our tests, but remember, the tool is just a tool. It's the insights you derive that make all the difference. Our latest experiment focused on the call-to-action button to connect your wallet. Initially, we had titled this button 'Join Wingman', thinking that the term 'Connect Wallet' sounded a bit too nerdy. Amanda Cassatt, author of 'web3 Marketing' book, even joked about it in her recent a16z summer school talk.

But we decided to test it. What if 'Connect Wallet' felt more familiar to our users? What if it actually resonated better? To our surprise, it did.

It's like the QWERTY keyboard - not the most efficient design, but it's too familiar to abandon. This simple test reaffirmed an age-old truth in user experience: Sometimes, what's familiar trumps what's new or cool.