Last week, I spoke about an interesting startup I read about - Superhuman. The hype around Superhuman is almost unbelievable, which motivated me to dig deeper. This week, I want to touch upon one particular aspect of product design in Superhuman that is unique and refreshing.

Before you proceed, you can find the detailed post (~10 min read) here. What follows is a summary for a quick read.

Rahul Vohra, CEO of Superhuman, was a game designer before he founded his first startup. He says he's always been obsessed with one question, "How do you design a game?". His obsession over building games is what motivated him to build Superhuman with first principles of game design.

It is so intriguing to see how the founder's background influences heavily the way a product is designed or built. But why is game design so fascinating to Rahul?

He believes games are designed to create emotional experiences and hence, are able to form a strong connect with users (or players).

Games don't need to exist. There are no requirements. When you are making a game, you obsess over how users feel and not worry about what they need or want.

When your product is or has a game, your users don't just use it. They play it, fall in love with it, find it fun and tell their friends. Hence, game design is worth doing.

But how do you apply principles of game design to product design?

Now, there are five elements of game design you need to know:

Goals - Goals are a defining feature of games. Every good game has goals that are concrete, achievable and rewarding. Most business softwares today have goals that are either unachievable or unrewarding and hence, users don't find the experience playful or fun.

Emotions - The best games create strong emotions. And it's important your product does too. For that, you first need to understand what these emotions are and for that, you need a vocabulary. A good place to start is to look at Plutchik's wheel of emotions and reflecting on how you could make your users feel these emotions when using your product.

Controls - Imagine you are playing a game like Street Fighter. You do a complex set of moves on your controller and say, your character flops. How would you feel? A good game always has robust and reliable controls. Unfortunately most business softwares today aren't designed that way.

Toys - There's a subtle difference between games and toys. You play games but you play them with toys. A toy in Superhuman, Rahul talks about, is the "auto-complete" feature. It’s just the box that you use to snooze e-mails or you type a few characters & punch an email for later. So for example, 2D will become two days, 3H will become 3 hours, 1 MO will become 1 month. Auto-complete is fun because it indulges playful exploration.

Flow - Flow is simply our state of mind and probably the hardest to achieve in game design. Flow is so absorbing that we don’t worry about the past or think about the future. Flow is so demanding that we don’t care about any other thing. If you have ever played a game, you would surely connect to how what I am talking about. There are five conditions to achieve flow which are enumerated in the longer post.

Now, you may not decide to design your next product as a game but you surely can ponder over these principles to see how best your product can emotionally connect with users.

I would love to hear what you have to say about game design. Do you have anything to add to this - from what you read, heard or experienced?

Until next time!

Cheers!
Hrishikesh
Founder, Flexiple and Remote Tools

At times, you come across products that defy the usual rules of business, product development or even logic. Apple and Ferrari are the frontrunners. There's no doubt that both have a huge, loyal following.

Another such product in the making is Superhuman. In fact, it has already been deemed as the Ferrari of email services in popular media.

Superhuman is an email app (competing with Gmail) and the buzziest startup of Silicon Valley in 2019. It has ~15,000 paying users and a whopping 220,000+ on the waitlist. The last funding round Superhuman raised was $33 million at an astonishing revenue multiple of ~45x.

But what makes this product so popular that people are ready to pay $30 a month just to check their email?

As it turns out, there's a lot going on here and there are a huge set of takeaways for us. Which is why I am writing a series of posts trying to unravel the mystery that is Superhuman

The first post is a breezy read where my intent is to set the context. Moving forward, you will see us speaking about topics that cover vast breadth. So stay tuned 😎

Here's a brief on what we will cover (or rather uncover) in this journey:

1. Lessons on personalised user onboarding

2. Targeting the HXC (high expectation customer)

3. Understanding the product-market fit engine Superhuman employs

4. How Superhuman executes principles from game design (building a product that users feel, not just the one they need or want)

5. Finally, the hard truth on why Superhuman works (to the level it does)

Here's the link to the post again - https://blog.flexiple.com/the-hype-and-mystery-that-is-superhuman-part-1.

Write again soon,

Hrishikesh

Happy Friday Product Geeks!

So I have this habit of checking out new products almost daily (mostly on Product Hunt) and I am amazed at the sheer magnitude and sophistication of these products 😯.

Take for instance, Notion. For those of you who don't know, Notion started out as a note-taking app and is now an all-in-one productivity app letting you create book notes, finance trackers, wikis and much more. There's even an entire website (and a set of courses) dedicated to telling people how to harness the power of Notion 😱.

Why shouldn't we then use these existing tools to build something that solves our use-case?

That's precisely my talking point in the third post. I will briefly run you through how to go about building a neat and robust Uber-like app using dependable existing solutions.

Go on, take a read and drop me a line if you like what you read :)

Here's the link again - https://blog.flexiple.com/a-practical-way-of-building-your-first-uber-like-app.

If you haven't heard about it already, there's a no-code movement in the making, where people talk about the power existing tools hold and harness it to build their own solutions. More on this in the coming weeks 🤓.

Product Stories - A New Initiative

Now, this is something I have been deliberating for quite a while now. I have always been curious to know the story behind the making of successful products and while at work, we very often engage in conversations critiquing products we see and use (in their current state).

I was thinking if someone else would be interested to read this commentary. So I went ahead and started writing the first post 😎.

Here’s the link - https://docs.google.com/document/d/1YV8_x_1ytnEi_czRqpXXUZEevHbKRIuYxEQNSNvuKBk

Now this is still a WIP (you will also see a few TODOs) and I wanted to share it with you early to see if and what you like/ dislike.

I would so love to hear your thoughts as comments on specific sections, the entire post or even the concept in itself.

If you enjoy reading my posts, it would mean a lot to me if you share it across with people who might find this interesting or helpful. Click here to email them or drop a note on social media.

Cheers!

Hrishikesh

I know it's been long since I wrote the first post on Uber's engineering and I heard back from quite a few people asking me when the next part would be published. There's always the 'busy with work' excuse but nothing explains such a long delay 😕.

So, here are a few commitments from my end on this -

1. The second post is now live (of course, otherwise you would kill me for spamming you without any content 🤓). Also, the third post in this short series on Uber would be live next Friday 😎

2. I would be publishing new posts every two weeks and you should see one mail from me every fortnight.

Now that is in order, let's quickly talk about the second post. This is a crucial connector in making the point around what (product) should you be building and when. Just because we understand how complex tech systems comprise of or how they are built, shouldn't push us to build such systems when not needed.

Have a read and drop me a line on what you think about this. I have made a conscious effort across the posts to share my learnings, experiences & opinions and not be preachy in any way. Do let me know if I have done a good job with this 😁

Until next Friday!

Cheers,

Hrishikesh

Uber's tech is mammoth. Studying and understanding it can prove quite helpful if you are venturing into building your own business or a product or even a new feature. Not because you should align with it from day one, but so that you never fall into the trap of building fancy, complex tech in the early stages.

Here’s how I have planned this part of the series:

1. We will start by understanding Uber's tech ecosystem

2. Next, delve into what you should (and should not be) building for your first product or feature

3. Finally, try to build an early version of an Uber-like app ourselves

In the first post, I would be covering point 1. Bear with me even if any of this seems a bit overwhelming, you will surely appreciate it once the journey is over.

To make things simpler, I have italicised terms throughout the post which should only be taken as examples and skimmed through (have also hyperlinked them as well though in case you are interested to read further on them). 

At all points, I would like you to only focus on the larger picture and not get bogged down because of the details.

So, go right ahead, grab a snack or drink and get to reading the first post

Do drop me a line at hrishikesh@flexiple.com in case you would like to engage in a discussion over any of the points or would like me to elaborate on something. 

You could also tweet to me @HrishikeshPard2 in case you would like everyone to benefit from the discussion. I am planning on sharing shorter snippets of content on Twitter, so, do keep in touch there as well