60 milliseconds is when we notice something isn’t immediate. Any user interaction, that involves sending data over the network or doing heavy computation on it, usually takes way longer than 60 milliseconds. So, we end with a progress bar. There are two broad categories of progress bars, one that shows the absolute/relative progress, a determinate progress bar, and one that does not an indeterminate progress bar.
When the code runs on your servers, you have much more control over the “context” in which it runs. On the mobile devices, the device OS and the user control the context. This difference leads to some subtle implications.
One significant set of differences comes from the lack of control of the platform. For server-side code, one can choose from a wide array of languages. For the mobile code, however, the best choice would almost always be the one dictated by the platform – Java/Kotlin on Android and Objective-C/Swift on iOS. Further, for the server-side where one can stick to a particular version of the language. In the case of mobile, the platform controls the language version. Same goes regarding the hardware choices – one can choose to use different types of server machines specialized in handling those jobs, eg. GPUs for math-intensive computes. While for the mobile-code, one had to write a good enough fallback to support a wide-enough set the devices. Similarly, the server-side has to rarely worry about the server killing a running process while it is normal for mobile OSes to kill backgrounded processes eventually.
The other set of differences comes from the temporary changes to the platform introduced by the carrier and the user. A network request running on mobile has to be robust enough to deal with intermittent broken connectivity to outright unavailability of a data connection, e.g., due to the user switching to the airplane mode. On mobile, network type matters as well. A network request on cellular would usually cost more than a network request on Wi-Fi to the user and a network request on roaming even more. On mobile, the code has to be aware of not doing unnecessary work when the user is low on battery. Server-side code is rarely subjected to such constraints.
Lastly, it is possible to parallelize and speed up the server-side code by adding more resources like RAM or better CPUs. If a certain number of servers are not enough, you can add more. There isn’t usually a way to offload compute-intensive or memory-intensive work off of the mobile devices without trading it off for network latency and sometimes, user’s privacy as well. While it might be preferable to go with a multi-processing approach in the server code to avoid concurrency issues, on the mobile, however, multi-threading being more straightforward and less resource-intensive is almost always the choice.
While iPhone is recognized as a global name while erstwhile Nexus and now, Pixel has almost no branding outside of the Android fanboys.
Further on Google’s naming snafu:
The bandwidth of different senses
Our brain loves distractions, and multi-tasking gets bored quickly. When we read text or watch a photo, it engages us visually, a video (with audio) engages us even more. The bandwidth of eyes is much larger than the bandwidth of our ears. When we are watching something, it utilizes more bandwidth and hence occupies more of our attention span. Also, given the way our eyes work, we can focus more on the exciting aspect of the visual feed. Compared to that, audio underutilizes our brain’s bandwidth. Further, the unidimensional flow of audio data at a linear speed does not mimic our ability to process it. Contrast forced direct listening with how non-linearly humans read.
How eyes jump forward and backward while reading
And that’s why video games are even more engaging than video. They utilize the bandwidth even further by forcing us to think and act in the game.
Since audio underutilizes our brain’s bandwidth, it leaves spare bandwidth for distractions, including eating food, driving, and exercising. No wonder most audio consumption is passive and happens as a secondary activity as opposed to being a mainstream activity like reading or watching movies.
The book consists of the learnings which the author had while working on his startup IMVU. The book focuses on the concept of validated learning and the build-measure-learn feedback loop. It tries to bring in a systematic approach to measuring the progress at a startup. A startup has a true north, its vision. It employs a strategy that includes a business model, a product road map, and a view of partners, competitors, and customers. The product is the result of the strategy. Products constantly change (engine tuning). Strategy changes occasionally (pivot). Vision rarely changes. In general management, failure to deliver results is caused by failure to plan or failure to execute. Both are frowned upon. But in the modern economy, both are useful tools for testing new ideas.
A startup is a human institution designed to create a new product or a service under conditions of extreme uncertainty. Success under such scenarios requires rapid experimentation.
There is a lot of learning involved in the process, and sometimes, when things go south, people resort to saying, “I learned a lot”. What’s more important is to figure out validated learning. The goal is to cut down to the absolute minimum effort required to learn what customers want and eliminate everything else. Eric Ries wrote 3-D avatars as IM add-ons for popular IMs in 2004. During the user testing phase, he realized that not only do users not understand what an add-on is, they also don’t mind installing a new IM software. A lot of heavy IM integration turned out to be a waste of effort. After this, Eric and his team launched several experiments regularly to test what works and what doesn’t.
Another counter-intuitive thing that IMVU experimented with is charging early. Many startups delay charging their customers. Not having any revenue is better than having low revenue since the former invites the imagination of overnight success once they start charging. The downside is that it can lead to the creation of a product no one is willing to pay. Conclusion: start with a low-quality prototype, charge customers from day one, and use low-volume revenue targets for accountability.
Nick Swinmurn had a hypothesis that people will buy shoes online. Rather than purchasing inventory upfront, he took photos of shoes at local shoe stores, and if the users bought it, he would buy and ship it to them. This minimum product tested customer demand as well as many other business issues like payments, returns, and customer interaction. Amazon acquired Zappos acquired for $1.2 Billion.
The Build-measure-learn feedback loop is at the core of the Lean Startup model. After building the MVP, the goal is to rapidly learn and iterate upon the product based on the user’s feedback.
All startups make some assumptions (leap of faith) about their viability. In the case of iPod, there were two assumptions, users would put earphones in a public place (“analogous to Walkman”), and they would pay for the music (“antilogous to Napster”). Only the second one was a leap of faith. Verifying these assumptions is paramount. Toyota does it via Genchi Gembutsu (“go and see for yourself”). Toyota’s minivan, Sienna’s chief engineer, drove through North America. He realized that kids are most appreciative of their environment and launched the new model with a particular focus on interior comfort for long trips. This lead to significant success for Toyota. Scott Cook, the founder of Intuit, believed that someday people would use a computer to pay bills and track expenses. He verified that the market for such a product by calling random people over the phone. One pitfall to avoid here is analysis paralysis. One can keep repeatedly talking to customers and whiteboarding over and over again. But many errors in such a strategy would go unnoticed since they depend on subtle interactions between the user and the product.
Groupon started as a “collective activism platform”. That assumption failed. Andrew Mason experimented with a WordPress blog and a mailing list to sell discount coupons. They had no fancy forms on the site. The idea took off, and slowly every aspect of it was automated. It is essential to get early results with a buggy product then to perfect about based on assumptions that might not hold in the future. It is counter-intuitive for entrepreneurs who want to build a high-quality product.
Drew Houston had a hard time convincing investors about DropBox. VCs thought that the market is crowded, no one made money, and the problem was not an important one. Drew believed that all that was because all the current products were of low-quality. Rather than spending years doing thorough integrations, he made an excellent video demonstrating the seamless behavior.
Wizard of Oz is a useful testing process for such situations. Rather than building an automated system, fake it with a human. It is faster for learning what users want.
Sometimes, a user’s quality metrics are very different. Users care about how much they enjoy the product, not how much time was spent building it. IMVU had no time to build a smooth movement of avatars from one place to another. So, they decided to and were ashamed of, cheat by making avatar re-appear at the destination instantly. Users rated this teleportation among the top three most liked features. Therefore, it is of paramount importance to remove any feature, process, or effort which does not contribute to the learning you seek.
Some entrepreneurs fear the competition that MVP will bring in, usually, from large companies. Most of the time, the Product Managers at the big companies are overwhelmed by good ideas. If not, they can still copy the product at a later stage. And the fear of being out-executed remains.
After building an MVP and putting it out for the early adopters, test the riskiest assumptions first. Now define a baseline metric, a hypothesis to improve the metric, and a set of experiments targeted towards the same. Once you have the results, decide whether to pivot or persevere. One of the biggest dangers is to get stuck with vanity metrics like total registered users. They paint a rosy picture but does not tell you whether the product improvements are making it better for the user or not. AAA (actionable-accessible-auditable) metric would measure the impact of a particular feature.
Grockit followed the Kanban model, where there are four buckets – backlog -> in progress -> built -> validated. Each was containing at most three features. After validation, either they made the feature or discarded it.
A startup’s runway is the number of pivots it can make. Votizen started as a social network for verified voters to discuss civic actions. That did not take off. Then it pivoted to @2gov, which allows users to recruit more verified voters for their petitions. This product has higher usage, but still, very few were willing to pay for it. They pivoted further to businesses as customers, who, despite signing the letter of intent, decide to eventually not buy the product. The final pivot was to use Google Adwords for acquiring users who want to pay to acquire more users. That worked out. Startup Visa Act was solely a result of that social lobbying.
Wealthfront pivoted from a virtual stock trading/gaming platform to an online service offering money management by professional money managers (ashishb’s note: and after the book was written, further to index-based investing).
Most entrepreneurs regret delaying the pivot. Vanity metrics, not having a clear success hypothesis, and being afraid of the failure, are the usual causes of delaying the pivot.
Types of pivots
When pivoting to a strategy followed by a successful company, it is crucial to copy the essential and not just the superficial features.
It is counterintuitive, but smaller batches are much better for lean startups. They appear inefficient but allow faster turnaround for the product leading to a more rapid iterative cycle. It helps in earlier detection of a problem as well as quick feedback from the customers. Toyota used the small-batch approach to compete with its much more capitalized American counterparts whose batch sizes were relatively bigger.
New customers come from the actions of past customers. They inform others, end up showing the product to others, or end up purchasing the product again. Sabeer Bhatia grew Hotmail by adding a signature “Get your free e-mail at Hotmail” to every outgoing email. If you are asking whether your startup has achieved a product/market fit, then you are not there yet. When the product/market fit happens, it leaves no room for doubt.
As a startup grows, it has to adapt to the changing customer base. Early adopters are more forgiving of the quality; later ones are not. Five whys help one to diagnose the problems and build the right set of things that should go into an employee training manual.
Big companies can innovate, but for that to happen, they should secure resources for internal teams, provide an independent development authority, and the internal team should get a stake in the outcome. Toyota calls the manager in charge of running the development of a new vehicle, shusa (Chief Engineer). The parent organization must be protected to create this platform for experimentation. If the existing managers feel threatened, they will have an incentive to work against the new project. Also, if such a unit is kept hidden, it will attract more political battles since existing executives will be wondering what else could be hiding. Therefore, any team should complete ownership to run an experiment and see the end-to-end results. Every company has to deal with four types of works – launching a new product, scaling it for the broad adoption, combating its commoditization by incremental improvements, and maintenance of the product in the long run as a part of the company’s product line. All the steps are essential, but the last stage of becoming the status quo is a hard one to swallow as an entrepreneur.
In 2001, Amazon’s share price crashed from 100$ to 6$, they had to do a 15% layoff. But it was Jeff Bezos’s perseverance, tenacity and grit because of which Amazon survived. As several startups from the Bay area to Bangalore get a mark-down of their valuations, the question about how many will survive and eventually produce a [positive] return for their investors is being asked. Between what a startup’s real value is and how viable is its business model, the real question to ask is how committed are the founder(s) to make things works. In the longer run, only that will matter.
Amazon Echo
Apple Siri, Google Now, Amazon Echo, and Microsoft Cortana have garnered a lot of press lately. But one thing which is still missing out is voice-native user experience.
Let me illustrate that with the evolution of user experience on touchscreens. When they first came out, there was a stylus, and that’s it. It was an inferior version of the mouse-keyboard-monitor trio. Then some fantastic interactions were invented. Interactions like double tap to zoom, multi-finger rotation, swipe to like/dislike, pull down to refresh, long-press for options, and a Swype keyboard. All of these were native to a touchscreen-based environment. Porting them back to a mouse-keyboard-monitor trio was of limited utility at based and useless at worst.
Yes, it did happen, and no, I am not stupid enough to execute rm -rf *. It was a bit more convoluted than that. I was trying to prepare a customized SD card image for the Android emulator. The fastest way to do that was to mount the SD card on my GNU/Linux machine and modify the files. The files on the SD card have root as the owner. Therefore, the easiest way to maintain a clean state was to make all modifications using sudo. My script included a command rm -r ${base_dir}/${old_file}. While executing the script, due to an error, both the variables were not set. It took me a few hours to recover; I never committed the broken script, so, I did not harm anyone else. But since then, my bash scripts have always included set -o nounset.
Standards exist so that products from different vendors can interoperate with each other, for example, sending email from Gmail to Yahoo! mail, and use common interfaces, for example, sockets for electrical appliances. The standardization does not always have to come from imposed standards; sometimes, it comes from the user expectations. For example, the interface of a Calander/Scheduling application is pretty standardized. There is little scope to differentiate a new Calendar application from the existing products like Outlook Calendar, Google Calendar, and iCal while just implementing the standard is still pretty hard.
One problem which standardization introduces for the product vendor is that there is little left to differentiate itself. For example, either the cables are compliant with USB-C standard, or they are not. The lack of differentiation produces perfect competition and hence, razor-thin margins. The model, thus, works only at scale. The same problem of standardization seems to have plagued products focused on email, calendar and RSS feeds. All three of them are pretty standardized. While one can provide a better UI like Sunrise does for Calendar, or over-the-top functionality like MixMax does, there is still relatively little scope for a product solving any of these to differentiate itself from others. Therefore, big companies with established distribution channels dominate.
The only exception to the rule is producing premium quality products, either in reality or perception and then wait for a niche market which will be willing to pay a premium hoping that they are getting the best product, for example, 41$ mini-USB cable and a 50$ MailMate email client.