I’ve been really liking Medium’s interface. So for now, I’ll be using them.

Today we are happy to announce Wildcard 2.0 is officially in the iOS appstore. The new Wildcard is the best news reader on the iphone, done through a combination of smart algorithms, good design, and a team of amazing editors. The past 7 months has been a process of constant iteration, and the new Wildcard shows a glimpse of our vision to the future of mobile media consumption.

When we started down the path of creating Wildcard 2.0, we thought along three different axis – speed, content coverage and personalization. A lot of design and engineering thoughts went into this, this post will cover some of our technical considerations.

Speed

The smart phone is fantastic. It’s a powerful computer attached to you 24/7. But this incredible accessibility is often limited by software. On average, it takes many times longer to read and understand a topic on the phone than on the desktop. It is quite ironic, that you would ever have to sift through web search results on your phone to find a piece of news.

We approached the speed problem from a fundamental level. Inside Wildcard, every piece of information is organized as a mobile card, which is somewhere between a tweet and a webpage. It is a small unit of content that captures a single use case – whether it’s an image, a video, or a summary and a link to an article. With the combination of a novel random forrest based card creation system (which I will write about in a separate post) and a card-based search engine, we have created what we call “the internet of cards” (IOC). Free from the shackles of the legacy web stack like HTML, CSS and Javascript rendering, mobile cards are represented with structured data and rendered natively. This nice property of mobile cards means we can truly deliver content with incredible speed, and natively change the presentation to any platform, whether it’s iOS, Android, FB, Twitter, or any smartwatch.

A few weeks ago, I attended a discussion panel about building design culture with Khoi Vinh from Wildcard and Pierre Valade from Sunrise. They are both designers I respect and admire tremendously, and I was surprised by the astonishing difference in their design processes. With so many variables in practice of design, how can we, as founders, try to build a design culture?

“Design is everything engineers don’t do.” — Khoi Vinh

“Design is everything, it’s how we solve problems.” — Pierre Valade

These quotes are much broader than the traditional understanding of design. It touches every corner of a company, and it requires a culture with tremendous empathy and understanding of the design process. So, to me, good design culture means everyone in the company has a certain level of understanding and appreciation of the design process. This is especially difficult to adopt, because shifting the mentality for a group of people takes time and consistent effort.

Design is having ridiculously high standard for product experience. Design is going above and beyond to delight users. Design is being obsessive about every little detail. Design requires numerous iterations and relaxed time constraints.

Predictability of shipping date goes down dramatically when the standard of design goes up. This means engineering needs to understand that 29 out of the 30 prototypes will not ship. This means marketing and PR needs to understand the marketing plan may start 2 months after the initial planned date. This means product needs to understand that design will gather information, get inspired from unconventional processes that sometimes seems like they are “wasting time”. And our job as a founders is to make sure we create enough space to make that happen.

One cannot simply build a design culture without having first-class design DNA. You can’t fake design culture by hosting the occasional customer interviews or getting employee passes to photography exhibits. Design culture is a commitment to the art and the process, and the first step to that commitment is to work with designers who REALLY knows what they are doing.

If you are just starting out with this process, there WILL be a period of time of learning to understanding where the lines are. I have been fortunate enough to work with some talented designers over the years, and here are a few things I have learned:

• Things WILL get thrown away. Figure out how to build CHEAP prototypes.
• The design process requires TIME and INSPIRATION. Sometimes it means browsing Dribbble for an afternoon, sometimes it means working in complete isolation for a few days.
• Don’t expect to validate everything in mockup form. A lot of times (especially for consumer products), you just have to play with the product.
• Subtle things REALLY matter. Things like typography make a big difference.
• Over-communicate, try to define a very clear goal at the beginning.
• Know that design is a never-ending process, sometimes things cannot be measured by metrics.

If you are not a designer, what other things have you learned working with a design team? If you are a designer, what other things do you wish your counter parts would understand?

There is a mantra in the startup world – “we only hire 10x engineers”. This is exactly the arrogant, bullshit attitude that turns your company into a fear-driven, political and unproductive place to work. Nobody is consistently a 10x engineer. Here is why:

If someone constantly works at a rate 10 times more productive than the average engineer, this person is an expert who has stopped challenging himself. This could be due to a variety of reasons, but trust me, the smartest engineers got there by constantly challenging themselves and learning new stuff.

In flow theory, the “flow state” is when the right amount of expertise and right amount of challenge intersect. This is a rare occurrence when you are productive at your highest potential. This is your “10x” state. Everyone can have this 10x state. (for more, read this post by Jeff Dickey)

However, almost by default, you are rarely in the flow state when you are working at a startup. Startups work on problems that have not been solved, and they are usually extremely challenging. You should have enough basic understanding in related topics to gain the expertise, but rarely do you already have the expertise. (Already having the expertise would mean you are working on the exact same problem as the one you solved before, and we have a much bigger problem here)

The mode of operation is usually something like this:

• Hit your head against the wall for a few days
• Search google, email friends, read papers / books
• Prototype a few different solutions, realize they are all flawed
• Cold email experts in the field (or get introduced by friends), set up coffee/skype meetings
• Build new prototype with newly gained knowledge
• Repeat

This process is filled with learning new tools, new terminologies and new ways of thinking. None of this qualifies for the prerequisite of operating at your 10x state.

Will you eventually learn all the things you need to learn to be productive? Of course. But that’s usually short-lived. You will get to be 10x when you are building the last prototype (which will grow into the real product). At this point you are so knowledgable in this particular topic that it takes you 10% of the time compare to the first prototype. This is your 10x state.

At this point, you realize the problem you solved is just one piece of the 3000 piece Seurat Sunday Afternoon Jigsaw Puzzle Now you have to move on to the next problem. And the seemingly never-ending death cycle of prototyping starts all over again. Oh by the way, you have to somehow magically align this effort with timeline on the business side, figure out a reasonable deployment strategy, manage your AWS instances, find time to see your boy/girlfriend, etc.

But there is a silver lining here. The more you go through this process, the better you get at navigating the unknown. You learn to use the right tools, you learn resources to look for, you meet other smart people, and most importantly, you learn to look at a unknown problem from an inventor’s eye. All of the experiences you’ve learned will increase your chances of entering your 10x state, and soon people will start calling you a 10x engineer. But you won’t let that get to your head, because now you know too much to know that you can’t possibly know it all.

So this is OUR mantra at Wildcard – “We hire ridiculously intelligent people and challenge them to constantly get better”. We are working on problems no one has solved, and we will constantly push ourselves to learn new things. May we never become 10x engineers.

5 months ago, Jordan, Doug and I sat in Doug’s living room in San Francisco for a week, talking about the mobile web and our visions of what it should be. It was an exciting week. Github account was created, AWS machines provisioned, and sketches were drawn.

We were all fed up with the current state of the mobile internet. It is an ecosystem plagued by terrible user experiences and little-to-no common practices. Users are left to their own devices and businesses lost precious opportunities. So we set out to change all that. Our goals are ambitious, our problems are hairy, and on top of that we decided to bootstrap, which means resources are scarce.

In the subsequent months, we moved back to New York, got a few desks at a co-working space (thanks to Lerer Ventures), and went to work. To better understand the problem, we talked to the smartest people we know, and created prototype after prototype.

We are still in the thick of it – changing the mobile web on a fundamental and infrastructural level is no easy task. It’s one of those rare projects that sit at the borderline between a completely crazy idea and a huge opportunity. This type of projects need time and a massive amount of effort. We will create infrastructure that the mobile web lacks today, we will create new modes for people to interact with “the internet” on the go, and we will invent new ways for businesses to reach their customers. The difference between now and 5 months ago is that now we have $3 million bucks, a few awesome new additions to the team, new prototypes to play with, and a new company name.

Our new company is called Wildcard. Jordan describes it well in his blog post about what we are up to, and Doug has posted about some technical problems we are working on.

Drop me a line if you want to learn more, or sign up for early access to the future by putting your email in the sign up form.

I’ve been thinking about intent lately. In the world of “big data”, “sentiment analysis”, “behavioral marketing” (blah blah blah…), “we use intent to drive user behavior change” is the party line. It’s a shame that “driving intent” is this black box that “our data scientists created” and no one else understands it. What does it really mean in the context of the internet we live in today?

To Lay the Ground Work

On the most fundamental level, every small action we do on a webpage is triggered by an intent. These are not “want to buy a car”, “want babies” intent. These are more like “click on name link”, “navigate to home page”, “sign up”, etc. Micro-view, super short-term, knee-jerk reaction type of stuff. From that we can define an “Intent” as “the desire of performing an action”, which really is the action itself + some meta data (like time, location, etc).

Now that’s quite a simplistic and lower-value view of Intents. What people really want is to derive “insights” from “intents”, which are the more “meta” intents people talk about in the advertising world (“want to buy a BMW”, “want to go to Daft Punk concert”, etc).

Let’s call the more insightful intents “meta-intents”, and the lower-level, action-representations “simple-intents”.

The Problem Of Predicting Intent

So what does it take to arrive at the “meta-intents” from a bunch of recorded “simple-intents”? When we translate it to “data science” terms, the question becomes “Given a series of prior simple actions, how likely is it for a person to take a particular action I care about in the immediate future?”

Statisticians have long studied this problem. Countless research studies have been conducted, ranging from brand loyalty, purchase behavior, to World of Warcraft and condom usage. Many regressions and latent-models and collaborative filters later, they all have one thing in common: the data has to be high-signal and low-noise. Said in another way, we have to know all of the relevant actions and at the same time filter out actions that are not relevant.

To put it in an example: in a cookie-centric world, an advertiser typically have about 10%-25% of the data. This means if I visited 100 sites this morning, they know about 10-15 of them. How high of a signal is that? How accurately can they predict what I’m trying to do?

In Real Life

Simple intents and meta intents inform one-another. We can derive simple-intents from meta-intents to guide users down to specific paths, and we can observe users’ simple-intents to derive meta-intents. But these 2 operations require different amounts of efforts. “Meta-to-simple” can be achieved almost automatically (mostly driven by algorithms), “simple-to-meta” is much more manual (data scientists or analysts validating assumptions on top of hadoop clusters). On by the way, it’s not obvious what those meta intents are so the assumptions are hard to make. Think the book Freakonomics.

From a cold-start, since you don’t have enough data to study any patterns of simple intents, ‘meta-to-simple’ is the only approach. There might still be room to use public data sets to generate meta-intents, but that’s a timed window as data science becomes commoditized over time. A data-driven product needs to have enough data science DNA in-house to continually experiment with new assumptions, and that’s how you build true advantages that no one else can copy.

There are a lot more topics to think about, like personal profile and short-term vs. long-term intent. We’ll talk about that in another post.

Brainstorming is an integral part of the creative process, and it’s especially true for software/product design.

The New Yorker published a great article this week titled “Group Think: The Brainstorming Myth”. The article tries to prove that “brainstorming” is not as efficient as “casual conversations”, mainly because it discourages criticism. Also see the linkbate on Hacker News “Brainstorming Doesn’t Really Work”.

The author makes great points about some downsides of brainstorming, backing it up with experiments and data. For example, the 2003 UC Berkeley experiment suggests that, groups who arrive to results through a “debate” process is often more productive than groups who use a “brainstorm” process, even though at times debating is unpleasant. On a slightly tangential topic, the author also brings up the point that “unfamiliarity” can increase productivity. (Backed by the Broadway production experiment conducted by Brian Uzzi at Northwestern) The article goes through many successful examples of modern work space setups that encourage casual conversations between multiple disciplines.

I totally disagree with what the linkbate suggests. (Although the article itself is quite interesting) Brainstorming and casual conversation have very different roles in the creative process. The points presented in the article are all valid, but the comparison is inappropriate. In a modern-day work environment, we need both.

Brainstorming is an organized activity. While it’s difficult to administor (therefore most brainstorming sessions are pretty poorly ran), it’s quite effective if implemented right. Here is why:

• It gets all the shitty ideas out of your system. Everyone has them, it doesn’t matter how smart/creative you are. Getting all the shitty ideas out of your head frees more mental space for you to focus on the good ones.
• It’s highly collaborative. It’s difficult to have a 5-way casual conversation. But having 5 different perspectives is super valuable. Sometimes 1 small idea changes the whole game.
• Most brainstorming sessions involve Whiteboards. This is good. Laying things out visually can again, free up more energy to focus on the hard problems.
• Breath-first vs. depth-first. For those who are not familiar with graph theory, BFS means exploring all of the adjacent points first, and DFS means go as deep as possible on one idea before exploring other ideas. Brainstorming tends to be on the BFS side, and that’s important especially at the early stage of a product.

I’m personally a huge fan of casual conversations. It’s a pressure-free and natural way to refine ideas and solve problems from other angles. These mini sessions can be extremely productive, but it’s kind of a hit-or-miss. To maximize the probablility of productive casual conversations here at Hyperpublic, we essentially sit in one big circle with the snack table in the center. Some of our best work come from casual conversations. Coffee trips is another good source of interesting discussions. When you are solving a technical problem, being able to talk to someone else while the problem is fresh in your head can be very productive.

Brainstorm and casual conversation are both important. They compliment each other in various ways, and the right practice of both can increase our productivity by leaps and bounds.