How to Use Your Alexa to Control Your Home Devices, Water Your Plants or Even Feed Your Cat

By day I'm a general partner at Initialized Capital helping founders and investing in startups. But I've never given up my hunger to build things and hack on projects in my spare time. So in that spirit, I wanted to share a quick tutorial:

In this tutorial, we'll walk through the basics of how to set up an Alexa Skill to control a Raspberry Pi or Arduino. Instead of having to water your plants with a button or turn off your lights with an app you just tell Alexa what to do and it will relay to your device. There’s a whole host of robot minions you can build (more tutorials coming soon!) but with this one I’ll demonstrate the very basic functionality and how to bridge Arduino and Raspberry Pi with Alexa. The tutorial is intended for engineers and should take about an hour.

Both the Arduino and Raspberry Pi have general-purpose input/output pins, or GPIO for short. GPIO pins are used to connect with other physical devices, such as lights or motors. These can be toggled between On (high) or Off (low states). In this tutorial, we’ll connect the GPIO pin to a relay with an LED light that will helps us verify that our code is working. You can use the GPIO for binary toggling or expand the code to any other functionality afforded by Arduino and Raspberry Pi (playing music, watering plants, robot army, etc.).

To send commands to our Arduino or Raspberry Pi, we’ll combine an Alexa Skill built with AWS Lambda with PubNub. Here’s an outline of how it works:

  1. Alexa listens for a voice command

  2. Alexa pings a AWS Lambda end point with the intent/command

  3. Lambda publishes the command to a dedicated PubNub channel

  4. The Arduino/Raspberry Pi is subscribed to the PubNub channel and is “listening” for any new commands

  5. The Raspberry Pi or Arduino receives command from PubNub and toggles GPIO Pin

0) Set up

In order to have a communication bridge between the Amazon Lambda function and the Raspberry Pi/Arduino we’ll need a shared communication channel that both can publish and subscribe to. Pubnub provides this service for free and makes it easy to use.

You’ll need to create a PubNub account and a new PubNub application. Let’s call application “GPIO Control”. Click into GPIO “Control” and you’ll see a “Demokey” set. Make note of the “Publish Key” and “Subscribe Key” we’ll need it shortly.

Screen Shot 2017-08-29 at 94352 PM copypng

1) Set Up An Amazon Alexa Skill

This is a detailed overview of setting up an Amazon Skill. If you’ve done this before, just copy the intents, and sample utterances, and skip to the lambda section. Remember to record your app id and keep it handy.

High level what we’re doing here is telling Alexa what phrase (“invocation”) we want to activate our app (“skill”) and then what commands (“intents”) to listen for. We also specify what end point it should ping when it hears an intent, in our case Lambda.

Make a new app

Go to https://developer.amazon.com/edw/home.html#/ click on “Alexa” on the top navigation, then select “Alexa Skills Kit” and on the “Add a New Skill”. Now we’ll give Amazon some information about the app, don’t worry about this as you can change all of it later:

  • Leave skill type as “Custom Interaction Model”

  • Type in “GPIO Control” for the name

  • Type in “Control” for the invocation (this is what we’ll say to activate this app)

  • Leave the other fields at “no” since we’re not using any of that

Click “save” and then the application ID will be generated. Keep this handy. We will need it for the Lambda function.

Screen Shot 2017-08-29 at 94555 PM copypng

Add Intents

On the next page you should see Intents. This is the actions your skill can take. In our case we want to be able to turn off and on particular GPIOs

For intents put in:

There’s a new schema builder available now, but to keep things easy let’s just use simple JSON. Now let’s enumerate what can be given to our “turnOn” and “turnOff” commands:

Under “Enter Type” put in:

LIST_OF_GPIOS

In the “Enter Values” textbox put in our individual GPIO pins (you can expand this to however many you have, I’m only using #5 in this example):

2

3

4

5

Click “add”.

This lists the types of inputs (in our case pin numbers) you can give to your “TurnOn” / “TurnOff” command. You can add more GPIO pins if you have more. For example, if you were selecting a type of tea this could be the list of teas or if you're controlling.

Define Sample Utterances

Now you’ll need to define what you say in order to turn the GPIO pins on or off. In the textbox under “Sample Utterances” put in:

TurnOn Turn on {GPIO}

TurnOn Turn {GPIO} on

TurnOff Turn off {GPIO}

TurnOff Turn {GPIO} off

AllOff Turn everything off

AllOn Turn everything on

AllOn All on

Feel free to add more. The format here is:

*your intent* (must be one of those you added above) *how to invoke it*

In our example  “All On” and “Turn everything on” both invoke the same intent (AllOn). To turn on pin 5 - you would say “Turn on five” and it would invoke “TurnOn” command with the GPIO value 5

Here’s an what my screen looked like:

Screen Shot 2017-08-29 at 113849 AMpng

When you are done, click next to go to the next screen

Define the endpoint

This is where you’ll tell Alexa where to ping when it gets one of those commands. It can be any endpoint. To make things easy we’ll use a Lambda function so we only pay when it’s activated as opposed to keeping it running all the time.

Select AWS Lambda ARN, “North American” for region and then we’ll detour to setting up the Lambda function.  We’ll come back to enter in the AWS Lambda ARN. Remember to make note of your Alexa app id as we’ll need it in the Lambda code.

2) Setting up Lambda

AWS Lambda acts as a serverless API. It lets you run code without provisioning servers ahead of time - think of it as an on-demand end point. This is perfect for what we’re doing since we don’t need a full-time server, just something to relay messages from amazon echo to pubnub.

Configuring Lambda

To set it up go to https://console.aws.amazon.com/lambda

Click “Create a Lambda function.” You’ll see a screen asking you to select a blueprint.

Screen Shot 2017-08-04 at 92941 PMpng

Click on “Blank Function.”

Next you’ll be asked to configure the trigger. We want to trigger it from Alexa passing on a voice command and execute code. So for trigger we’ll choose “Alexa Skills Kit”

Screen Shot 2017-08-04 at 93030 PMpng

Now we’ll name our function (eg. “controlgpio”) and select “Node.js 6.10” for the runtime.

Last step is to configure “Lambda function handler and role”, keep it on the defaults:

Screen Shot 2017-08-06 at 44027 PMpng


You should be all set to create your function. Hit “next” and “Create Function.”

At this point you should have an ARN generated that we can use as the “endpoint” for our Alexa Skill. This is where Alexa will ping when the Alexa skill is turned on or hears one of our intent.

To do this go back to Amazon Alexa page and paste the ARN that was just created into the textbox asking for an end point:

Screen Shot 2017-08-29 at 100357 PM copypng

Hit next and you should be all set!

Lambda Code

Go back to Lambda page and provide the code for handling the commands. I’ve made it into a zip to make it easy - 

The zip contains:

  1. Our code for getting a request from Alexa and passing it along to PubNub;

  2. The base Alexa library; and

  3. Required node libraries

After you download the .zip, go to  index.js and modify the app id to the Alexa app id (see above) and PubNub keys (from the first step). You won’t need to change the other files.


Looking at the code you can see that it handles incoming requests (from Alexa), puts them into json and publishes them to a PubNub channel. We will then subscribe to that PubNub channel and listen for any requests. It will be the same for Raspberry Pi or Arduino since it’s just communicating with the PubNub channel.

I’m handling 4 cases:

  • Turning on a particular GPIO (1)

  • Turning off a particular GPIO (2)

  • Turning all on (3)

  • Turning all off (4)

The intents are being translated from words to ints to make it easier for the arduino to handle (mine has very limited memory).

To try out other intents just add them to the GPIO.prototype.intentHandlers array, rezip and reupload. You can see lots of examples in the official Amazon documentation: https://github.com/amzn/alexa-skills-kit-js

When you’re done modifying the app id and PubNub keys, save it, zip all the files - node_modules, index.js and alexa.js (don’t include the containing folder) and then upload the zipped file to Lambda.

You can read more here if you’re interested - https://docs.aws.amazon.com/lambda/latest/dg/nodejs-create-deployment-pkg.html

Testing

Now let's make sure everything is working!

First we’ll verify that there’s nothing horrendously wrong with the lambda code and we can start a new session. To test this select action -> “configure test event”

Screen Shot 2016-11-06 at 65409 PMpng

Paste this into the code section over the existing code (it’s a modified version of the start session template)

Change the applicationId to the Alexa skill you created and hit “save and test”. It should have a green box saying “Execution results: succeeded”.

Now let’s simulate a request from to turn on GPIO 5 (Once again you’ll need to modify the app id to be your app id):


eg.

Screen Shot 2017-08-29 at 93204 PMpng

You should see the success message and if you expand the logs it should say:

{
 "version": "1.0",
 "response": {
   "outputSpeech": {
     "type": "PlainText",
     "text": "Turning on 5"
   },
   "shouldEndSession": true
 },
 "sessionAttributes": {}
}

Yay! We should also make sure it was successfully published to the PubNub channel:

Log back into your PubNub account, select your app and then on the left hand side (at the bottom) click on “debug”. You might already have a client subscribed “hello_world” otherwise just add it and verify that it’s successful by looking for the message being passed to the channel:

Screen Shot 2017-08-29 at 82208 PMpng

You should see your request (1 is the action to “turn on” a particular gpio) published to the channel you’re subscribed to. If you don’t see it make sure you have the right pub/sub keys and you’re communicating with the same channel.

Now let's test all the pieces and make sure the whole flow works by simulating a request from Alexa. In the “service simulator” on the “test” tab in your Amazon Skill pass in the following command:

Turn on 5

To simulate GPIO 5 being switched on:

Screen Shot 2017-08-29 at 115950 AMpng

You should see a response from Lambda and a command in your PubNub debug interface.

Screen Shot 2017-08-29 at 82331 PMpng

Success! Now that we have publishing working lets subscribe to it on the Raspberry Pi and Arduino.

3a) Arduino

Connect to the Internet

First we need to connect Arduino board to the Internet over WiFi. I used an ESP8266 WiFi shield. It doesn’t come with headers soldered to the board, so just buy them seperately and solder them on. Then attach the shield to your Arduino. You could also use an ESP8266 Module and just wire it up directly

Then we’ll use the SparkFunESP8266WiFi library to connect your shield to the internet.

To include the library via the Library Manager, from the drop down select Sketch -> Include Library -> Library Manager and then search for “SparkFunESP8266WiFi” and restart the Arduino IDE. A more thorough guide can be found here: https://www.Arduino.cc/en/Guide/Libraries

Test that your board connects to WiFI with the following code (this is just modified example code from the ESP8266 library):

Upload that code to the Arduino and then open up serial monitor (the little magnifying glass on the top right). You should see it successfully connect to your wifi and then print the results of your get command, in our case an empty array and a timestamp from pubnub:

Screen Shot 2017-08-29 at 120741 PMpng

Setting up your Arduino

Now that we are connected to the internet, let’s set up a visual indicator of whether our code is working. I’m going to use a relay since it has a built in light indicator

The relay has 3 inputs:

  1. Power (+)

  2. Ground (-)

  3. Signal

Connect power to 5v/vcc and ground to one of the GND pins and the GPIO 5 for the signal pin. When GPIO 5 switches to “HIGH” the relay should light up, when it’s on “LOW” it should be dark.

Subscribing to PubNub channel

In order to receive commands from PubNub, you’ll need to subscribe to a channel and wait for Lambda to publish something to the same channel. Arduino has a useful built in “loop” function that predictably loops and executes any code in the function repeatedly, we’ll put our code into it to ping the channel repeatedly and see if anything has been published to it.

You can do this via PubNub’s REST API and do a GET request in the loop or use the PubNub Arduino library and modifying it slightly to make it compatible with ESP8266. In both cases we’ll need to parse the json result.

If you have a mega2560 or board with more than 2k bytes of memory, you can modify the example code provided by PubNub (just change the client to be esp8266) and use the aJson library. My Arduino didn't have enough memory for it so I used the ArduinoJson library. You can see it pings the channel and then if it catches a relevant command it will execute:

You’ll need to configure the code with your wifi and PubNub keys.

Upload to your Arduino and open up serial monitor again, you should see it having successfully connected to your internet and be pinging the channel for any updates.

Now go into PubNub debug console, for the channel select “hello_world” and send a command just like what lambda would give:

Screen Shot 2017-08-13 at 103212 AMpng

You should see the command show up in your serial monitor:

Screen Shot 2017-08-13 at 104903 AMpng

If you don’t see it make sure you’re using the right keys and are on the right channel.

Now let's test the whole thing. As before go to your Alexa testing tab and under "enter utterance" type in:

Turn on 5

Verify that it’s pushed to PubNub as above and that it shows up in lambda serial monitor:

Screen Shot 2017-08-29 at 21533 PMpng

and that the relay turns red!

Success!

3b) Raspberry Pi:

This tutorial is in python, I have one in nodejs coming with a longer tutorial on how to build a tea robot. Hope you find it useful!

Set up

Get a Raspberry Pi, make sure it has a WiFi card (buy a usb one if it doesn’t) and get connected to your WiFi network.

Optional: I’m going to use the same relay as in the arduino tutorial above to indicate whether the pin is on high or low. Connect the power (+) to 5v, ground to gnd and signal wire to pin 5


piwireup2png


Next install the necessary Python libraries on your Raspberry Pi, type the following commands into the command line:

sudo pip install 'pubnub>=4.0.13'

sudo apt-get install python-rpi.gpio

Code

Next, create a Python file called “gpio.py” with the following code:

https://gist.github.com/anonymous/163110e743837ea48912fc9f365bdda2

In terminal run it via “python gpio.py” and you’ll see it say “Waiting for Commands”. Now go into your “service simulator” as above and tell it to turn on pin 5

Screen Shot 2017-08-29 at 90200 PMpng


You should see it show up in your terminal:

2017-08-30-040348_656x416_scrotpng

And see the relay turn on/off.

raspberrypijpg

Success again!

Conclusion

Now that you’ve successfully issued your first voice command to your Raspberry Pi or Arduino, you can quickly iterate on this setup to perform far more elaborate tasks. While I mentioned a few ideas earlier(*cough* robot army *cough*), I’d love to see what creative projects you come up with! If you can, please share videos and comments with me at [email protected]!

Why We’re Backing IUNU in Creating The Next Generation of Greenhouse Systems

IUNU founder Adam Greenberg, who is building the next generation of greenhouse technologies with modern sensors and machine learning.

At Initialized Capital, we will get on a plane if we hear of company that we think can return our entire fund. We really mean it. Our third fund has invested in ten companies outside the Bay Area.

When we first heard about IUNU from Mike Miller of Liquid 2 Ventures, we quickly booked a flight north to Seattle. The son of a botanist and an alumnus of Amazon, founder Adam Greenberg is creating a future for greenhouses and more efficient agricultural yields through sensors and artificial intelligence. Through an introduction from a mutual patent attorney, Greenberg teamed up with engineer Matt King, who had worked on Boeing’s manufacturing systems, to do computer vision for greenhouses.

When we arrived, we found Greenberg running a complex greenhouse system with every single plant under camera monitoring. From an iPad user interface, you could zoom in on individual plants and track every single leaf.

IUNU’s vision is to provide the operating system for greenhouses — a network of overhead cameras captures photos of every single plant, every ten minutes. This comprehensive set of data allows growers to track imperceptible differences in plant health before they can be spotted with the naked eye. The controlled environment of a greenhouse is the perfect place for an machine learning and data feedback loop where the impact of grower actions can be evaluated against precisely measured results. The goal is to bring to growers the same rapid iterative development cycle so prevalent today in the software industry.

North American greenhouse square footage is growing 20 percent annually with demand for organic produce outstripping supply by a four-to-one margin. Climate change will only make outdoor farming more challenging, thus driving more production indoors. This problem is especially acute in foreign markets that are not blessed with the great weather or soil conditions for farming vegetables that we enjoy in California. So it isn’t surprising that only one percent of the world’s 109 billion square feet of greenhouses is in the U.S. Many of IUNU’s most promising opportunities are outside of the country in Spain, the Netherlands, Mexico and Canada. Even Dutch indoor flower growers, who are facing wastage rates as high as 30 percent, have expressed interest.

IUNU has the chance to become an agriculture technology leader with deep moats for an enormous market. They are not another capital-intensive, low-margin tech-enabled indoor growing operation. They sell high-margin software that is difficult to get right and they have a data advantage for computer vision that grows with every customer and plant varietal they on-board.

There are network effects once resellers like Lowes, Home Depot and Whole Foods demand their growers have capabilities for predicting supply. This product is also extremely sticky as customers are not likely to switch after they have installed camera hardware throughout 30 or 40 greenhouses. This hardware, by the way, gets better and cheaper every year and the team has a laundry list of ways they will improve on their current installation design and process. Finally, the future of this company is in the data they will analyze across greenhouses, which will give them insight into new markets and products for predicting profit and financing receivables.


In sum, IUNU has an innovative, difficult-to-build product for a large and rapidly growing market that is underserved by software. The business has moats on moats and is led by the quintessential founding team.

Why Initialized Capital Invested in Open Listings

Buying a home has gotten easier, faster & more attainable with software

Homebuyers don’t want an agent. They want a home. Here I am in my home, thanks to Open Listings.

In 2015, I needed help buying a home in San Francisco and turned to the founders of Open Listings. It was quick and painless. I knew what I wanted, and they were able to get me that home on my terms.

A few months ago, we caught up with them again in LA to talk about their business, and it became quickly obvious that they had made a lot of progress. What these founders have done since graduating Y Combinator in the Winter of 2015 is remarkable. They’ve built a product that delights customers — they closed over 64 homes last month alone — and saved buyers millions. (Open Listings splits 50% of the commission with homebuyer, which is $8,000 on average).

It’s a win-win situation for their buying agents as well. The key? Efficiency.

Traditional agents normally spend 80% of their time looking for new clients or driving potential buyers around. Since buyers come to Open Listings directly and browse homes on their own time, agents only have to focus on getting offers accepted. This allows them to pass the savings along.

With housing prices steadily increasing, this commission refund is real money for the young families, first-time homeowners & immigrants that turn to Open Listings. As house hunting becomes more digital, software efficiency should save buyers time and help make home buying more affordable. We continue to be excited by founders who show relentless discipline and commitment to making something people love. They’ve done the hardest part, and now it’s time to focus on growth. The Initialized team is thrilled to roll up our sleeves and dive in.

It certainly doesn’t hurt when one of us is already a very happy customer.

Go ahead, start househunting!

Why Initialized Capital Invested in AdQuick

We love the idea that file-cabinet industries are doomed. People are used to world-class software for taking photos of their kale salads at lunch, but come back to the office to do their jobs using terrible or no software. That’s an opportunity. You can see the theme in our seed investments investments like FlexportOpenDoor, and Bellhops. Today we’re announcing that we led the seed round in AdQuick.

Buying out-of-home advertising is no exception: information asymmetry, multiple phone calls, and dozens upon dozens of emails and attachments. And it’s a $40 billion global business that’s not going away if you believe we will keep leaving our homes. It’s also the only growing traditional ad medium.

Wasted time, human error, and unnecessary costs can be curbed with software and Adquick was the first of these companies promising that future who actually delivered a quality software product in the present. I’m no stranger to buying billboards, so the concept resonated with me immediately, but it wasn’t until Garry and I sat down with the founders (former Instacart [Fund I] employees) that we saw how diligent they’d been with little to no funding.

We’ve seen pitches for this business for almost a decade, but this was easily the most impressive technical execution and at a remarkably early stage.

Starting a company in the internet age means you don’t need to open a factory, you only need to open a laptop, but far too few founders have as much to show for it as Matt, Fahim, and Connor did. A modern, searchable map interface combined with unique tracking data to help marketers show elusive ROI on out-of-home ads made this a really formidable pitch despite only being a 5 month old business.

It helped that I’ve ordered some outdoor advertisements, but the reference checks ranged from incumbents like H&R Block to upstarts like OVO all came back effusive. If a range of customers, who learned about you organically, love your b2b product that much and you’ve only just begun — we’re interested.

What To Do If Your Product Isn’t Growing

How ‘Critical User Journeys’ can help a product take off

As a founder, product lead at Pinterest and PM for a couple products at Google, as well as a growth partner for Initialized Capital, I’ve seen many product teams struggle to grow. Many products start out with a bang. Some find product-market fit with sustained growth. Few have gone through spurts of hyper-growth. But more often than not I’ve seen most of them linger then fizzle.

Throughout these experiences, I have noticed a common pattern that almost every startup founder falls into as they begin this journey. Founders launch their product, wonder why it isn’t growing like gangbusters and then immediately try to fix their growth problem.

They turn to growth tactics like optimizing their on-boarding funnel, SEO or push notifications before really understanding what they are building and who they are building for. This may create an initial burst of short-term growth. But it ultimately leads to high churn of your possible customers, while ignoring problems in the core product.

Before trying different growth tactics like throwing spaghetti at a wall, startups need to take a fresh look at their users, evaluate their product end goals and re-define the journey they want their users to take to get there. Here are some tips that can help define a path which will clarify the different steps needed to unlock product growth.

Map out your ‘Critical User Journey’

Many startups build a product without knowing what path they want their users to go down. If you look up the phrase “Critical User Journey,” you’ll find a plethora of UX frameworks and user maps. These are great, but can be overwhelming and daunting.

Early startups should start simple and make sure they know the optimal journey they want their product to fulfill for the user.

Your Critical User Journey should focus on a single use case with a specific goal and include the surrounding context for the user. For example, one of the journeys that Pinterest is focused on is helping a user find ideas around their own personal style. A Pinterest user typically starts from browsing a large visual catalog of style ideas, and then progresses to discovering the right looks that fit their own style.

Then Pinterest allows users to curate their own look books, style boards and eventually make it seamless to buy those looks, whether that’s directly on Pinterest or through a deep link to the merchant. The happy case is that the whole journey is completed on Pinterest. Now Pinterest has grown over the years to become a large company and fulfills multiple user journeys.

Pinterest guides users through each step of Personal Style Discovery: Browsing, Filtering, Curating, and Fulfilling

Founders starting out need to have clarity on the specific ‘Critical User Journey’ they are fulfilling. Then they need to understand how their product helps users along each step of that journey.

Measure your ‘Critical User Journey’

Once founders have a crafted a user journey, they need to be ruthless and specific on how they measure it. All successful startups have a plethora of top-line metrics (or KPIs) they measure and there are many great tools to help visualize this. For startups just starting out, it’s very easy to fall into choosing vanity metrics like MAU (Monthly Active Users) or a sum total measurement metric that looks like it is growing and lose sight of what is actually happening.


source: https://blog.kissmetrics.com/throw-away-vanity-metrics/

Instead, early startups should start with actionable top-line metrics to measure each step of the Journey. Start with two metrics: One user acquisition metric at the top of the funnel that measures how many new users are signing up and taking their first action. And then one user engagement metric further down the funnel that measures how often these new users engage with the product over time. Together, these two metrics define a product’s activation rate in how it graduates new users into becoming active users. From here you can add additional top-line metrics that are specific to your product and user journey.

The more specific top-line metrics are to a product’s user journey, the better they are at helping startups make decisions.

For example on Google Assistant, we measure user activation based on the user making at least one successful query that day on a specific surface (i.e. Pixel phone) in a specific country (i.e. U.K.) using a specific feature (i.e. Ask about “My Day”) within their first two weeks.

Identify ‘product levers’ that help move users along their journey.

Many startups chose top-line metrics but are not able to directly move any of them in a measurable and systematic way through projects and work streams. Having numbers to measure is only good if you know how to move them with the right product levers.

A product lever is something that is moveable and measurable that connects projects your team is working on on to top-line metrics that you care about.

For example, one of Initialized Capital’s portfolio companies I worked closely with chose the top-line metric ‘L7 Engagement,’ or the number of days a user has been active on the product during the last seven days). They chose the primary product lever to drive this as “Additional Actions taken per User.” They narrowed down the projects they were working on to only ones that drove additional actions per user (such as showing more in-line suggestions, creating off product promotions, sending contextual follow-up notifications, etc.) and cut the ones that didn’t. They saw their L7 Engagement rate turn around after a few experiment cycles and they expanded their focus to an additional product lever to drive L7 Engagement.

Don’t add so many features that the ‘Critical User Journey’ becomes obscured.

Another common pitfall all founders are pulled into is to “fix” growth by adding more and more to your product to “see what sticks.” Growth by product addition is hard to measure and rarely scalable.

For example, I worked with one portfolio company that had a great product serving a user need. They were driving a meaningful metric yet they were seeing stagnant month-over-month growth. Upon looking closer, we saw that they had built multiple convoluted activation flows on top of each other. Each flow they released showed slight overall gains, so they kept going and building more flows on top of each other. Soon enough, they couldn’t tell which flow was directly responsible for retaining or losing users. Their product became a Rube Goldberg machine spitting out one user at a time.

A Rube Goldberg machine — complicated mechanics for a simple output

Once we simplified the product down to one activation pathway with each flow directly moving a specific product lever, their conversion rates went way up. This was mostly because their product became simpler. It was easier for users to understand and easier for the company to see what was going when users got stuck.

Taking a step back to simplify and focus freed the product to grow.

Let your most engaged users show you the way.

This one may seem obvious, but sometimes users have done the hard work for you. Startups should look at their most engaged users and deeply understand the actions and pathways they took to get there.

Find a cohort of your most engaged users and look backwards. Identify what actions they took the first day, the week, the first month, and subsequent time periods to get to their state. Identify these actions as pivotal moments you want new or casual users to take at each step of the journey. For example, if taking four actions in the first week led users to be more engaged the second week, prioritize these actions for new users in their first week over anything else.

Create engagement loops around these actions to encourage users to continue down the pathway to take another action after completing a previous action. And of course, measure and monitor how many users are taking these actions at each step of the journey to see the holistic engagement picture of your product.

If you know exactly what actions and steps your best users took, you should try to replicate their journey for others.

Defining one ‘Critical User Journey’ for your product is a start and will serve as an early guide to define metrics, clarify what users need to do at every step, and help prioritize the right product levers to create sustainable growth.

When you are ready, this framework can expand to several user journeys that either deepen engagement of existing users or broaden use cases to reach new sets of users.