DEV Community: Katie Hindson

How we do product planning at Lightdash

Katie Hindson — Thu, 10 Mar 2022 10:43:40 +0000

We’ve finally found a product planning approach that works for us

The speed and ambiguity that comes with building a new product can be lots of fun, but it can also make planning super tricky. At an early stage company, you don’t know where you’ll be in 6 weeks, let alone in 6 months. But, that’s half of the fun of startups, right?

We started building Lightdash less than a year ago, and the way we do product planning has already changed a few times. At times our planning was bad, sometimes it was okay, but it never felt great. It felt like planning was blocking productivity instead of enabling it.

The main problems were a combination of:

we were trying to plan too far in advance
the plans were too rigid, so they became irrelevant really quickly
it wasn’t clear when or how our plans should get updated over time

Then, we came across Ant Wilson’s blog post about how Supabase does launches, and we decided to try a version of this for ourselves. Spoiler alert: it went really well.

In the spirit of being open about how we’re building Lightdash, we wanted to share the process for product planning that’s been working for us. We’re also hoping that this might be helpful for other folks on the hunt for a better product planning process :)

We plan for 6 weeks of work, release things when they’re ready, and shout about what we’ve built at the end.

^ That’s pretty much the one-liner summary of how we do product planning at Lightdash.

In the past, we tried planning for 6 months in advance, quarterly planning, and a blend of timelines, but we found that things changed so quickly and we were just continuously updating our plans. This is why we landed on planning 6 weeks of work - shorter than a quarter, but longer than a month. It’s worked for us.

So, in the rest of this post, we’ll outline the product planning rituals, the timelines, and links to all of the resources that we use for our 6 week planning cycles.

The process is broken up into 6 bits:

Planning
The Kick-Off
Get to Work
Prepping for Demo Week
Demo Week
Rest + Reflect

Let’s dig in!

1. Planning

The planning phase is where we (surprise, surprise) plan the work we’ll do in our 6 weeks of building time. This is the phase that has the most meetings, but investing in the planning at the start is totally worth it!

All things Lightdash (30 minutes):

Summary: Google Jamboard where we brain dump terms + concepts related to Lightdash. What we're building, who it's for, what our goals and metrics are.
Goal*:* get everyone loaded up on what’s happening across Lightdash. Get the “obvious” stuff down so we can move onto more creative thinking later!
Resources: All Things Lightdash - Template

The great metrics review (45 minutes)

Summary: Are the metrics we’re tracking still relevant? If yes, which ones should we be trying to improve and why? Are we missing any important metrics?
Goal: Everyone should have a clear idea of the metrics we’re trying to improve (before we brainstorm ways to improve them).
Resources: The Great Metrics Review

The ideation situation (1h45 minutes)

Summary: what are we going to build or do that's going to move the needle? List down as many ideas as possible. We’ll be sorting and filtering as we go. The scope of these ideas is flexible! Some ideas may take 1 week to build, some may take 20 - if we don’t finish it before launch week, we can finish it in the next build cycle 😊
Goal: Have a list of ideas of things we want to do/build
Resources: The Ideation Situation

Making the cut (45 minutes)

Summary: We use the RICE prioritization framework to filter and prioritize the ideas that we came up with. Then, we pick the top 6, assign owners to them and bring them to the break out sessions.
Goal: Get a shortlist of ideas that we want to bring to the breakout sessions.
Resources: Making the Cut

Break outs (~30 minutes each session - optional to run and not everyone attends)

Summary: These are sessions that are optionally booked by the idea owners.

The idea owners should take some time filling out the Break Out Template for their idea. Once they’ve done this, they can decide if they have some questions that they want to talk through with some folks from the team and book a break out session. Or, they can just share their completed Break Out Template for the rest of the team to read and give feedback independently.

The break out templates are meant to help you you can flesh out the idea and decide whether or not it’s actually worth building (ideas can die after completing a break out ☠️).

If an idea survives, there should be a general plan of clear next steps + what work needs to get done (do we need user research? do we need to plan/partner with another company? do we need to find a new tool to do the thing we want to do?).

Goal: Decide whether or not an idea is something we actually want to pursue building. If it survives: we should have a general plan of work + clear next steps that we need to take for building the idea. Copy a break out template and complete it for your idea.
Resources: The Break Out Template

2. Kick-off

Now that you’ve done all of the planning, it’s time to actually kick-off the work. The team’s had a chance to think a bit more about the suggested ideas, so this is an opportunity to make a final cut or change the priorities for the next 6 weeks.

Can I kick it? (1 hour):

Summary: We’ve completed any break-out sessions or chats we needed so we have a pretty good idea of what we want to aim for in the next 6 weeks. We remind everyone of the goals we’re aiming for, the timeline, and the current list of ideas we want to build.

We decide on which project we want to get started with.

Goal: Everyone should have a clear idea of what we’re aiming for at the end of the 6 weeks and be ready to get to work after the kick off!
Resources: The Kick-Off

3. Get to work

Summary: This isn’t a one-off meeting. This is the 6 week period where we start to work on the goals we planned. We ship features as they’re built and log our changes for our Demo Week.
Goal: build the stuff!

4. Prepping for Demo Week

We’re a couple of weeks out from the chaos of Demo Week - so it’s time to start planning and prepping so everything runs nice and smoothly :)

The content event ( 1 hour)

Summary: In the 3 weeks leading up to the Demo Week, we review what we actually want to demo, plan for what supporting materials we'll need and decide on which channels we want to push the content to.
Goal: Have a plan for the content + other things we need for Demo Week!
Resources: The Content Event

Love, peace and pre-Demo Week release.

Summary: Everything that we want to be demoed in Demo Week should be ready/released the week before. We talk about blockers, any content that we’re missing and assign people to review + test everything before Demo Week.
Goal: We know what needs to be done before Demo Week and we have people assigned to doing it.

Big fans of plans

Summary: This isn’t a meeting, it’s just a reminder. We have planned each day of the Demo Week: what we’re announcing, where we’re announcing it, when it’s happening, and who’s responsible for doing it.
Goal: We have a plan for each day of Demo Week.

5. Demo Week!

Yay, it’s Demo Week!

Summary: Every day we have a catch up in the morning, talk about blockers, and review the launch plan for the day!
Goal: Remove blockers, get stoked!

6. Rest + Retro

Summary: We take a week-long rest to chill, do some less critical work, catch up on sleep, do anything we didn’t have the chance to do during Demo Week.

Retro on the planning cycle! Do we want to do Demo Week again? Is this more or less effective than how we worked before? What went well, went badly, can be improved?

Goal: Have an idea of what we can improve, and what we should keep for another product planning cycle.
Resources: Reflect and Retrospect

And that’s it!

There you have it: our product planning approach at Lightdash. Hopefully some of these sessions are helpful if you need some inspiration to change up your product planning or if you’re just interested in how we do things here at Lightdash..

If you have any questions, or ended up trying it out for yourself, we’d love to hear about it!

You can shoot us an email at info@lightdash.com

SQL queries I wish I'd known when I started in data. Part 1: the event funnel.

Katie Hindson — Mon, 21 Dec 2020 11:34:44 +0000

SQL worth remembering.

Hey! I'm Katie, a product data scientist here at Hubble 👩🏼‍💻

Something I've noticed since joining Hubble a little less than two months ago is how much SQL I have stuck in my head. These are queries that I find myself reusing over and over again at every place I work and once I used them once, I couldn't forget them.

So, I thought it might be worth sharing these queries in case it's useful for others 🤗 And that's exactly what I'm going to do in this series of blog posts.

I'm going to go through some of the most common SQL queries that I whip up when digging into a product's performance. I'll also talk a bit about how you can use this data to help you make better product decisions.

So expect to get some insight into building:

event funnels
gapless date grids
tables that let you do time-series analyses on your users

Once you've built these common queries, you can use Beacon to save them so all of your team can access them without ever having to write the SQL. You can also use Beacon to share the results from your shiny, new queries right in Slack! You can check out Beacon here.

Being a "data driven" company can feel like a pipe dream at times, but hopefully these blog posts can help your team make it a reality 💪.

Use event funnels to track a series of events that users can take - and to improve the journey!

One of the most useful bits of data I dig up when first launching a product comes from an event funnel.

An event funnel is a tool that lets you measure the completion rate of a series of steps (events). For example, you might create a funnel of the steps you need to go through to create an account, and then track the completion rate of each step.

With these funnels, you're able to see which steps are the biggest drop-off points in the user journey. This information is really useful, because:

You can make data-informed decisions about what parts of the product you need to change to increase completion of an action (instead of relying only on your intuition).
You're able to estimate the impact that your change made on the completion rate because you can compare the funnel before + after the change.

How we used event funnels to drive higher engagement with Beacon.

We built a product, Beacon, that lets you write, run and share your SQL in Slack (you can add it to your workspace here!)

Once we launched it, we wanted to understand how users were engaging with the product. Specifically, we wanted to figure out why people weren't running a query with Beacon after installing it.

So, we have an action ("execute a query") that we're trying to optimize the completion rate for, and we know the steps leading up to that action. Enter...the event funnel.

I built an event funnel for users starting at "I installed the app" and going to "I executed a query". I used our awesome tool, Beacon, to run the query and share the results directly with the team in Slack:

...

This event funnel makes it really clear that the biggest drop off point is between steps 3 and 4: seeing the connect modal (i.e. the screen giving instructions about how to connect to a database) and successfully getting a database connected.

So, we reached out to some of the users who got stuck at this step and brainstormed some improvements that we could make to help reduce the friction in getting a database connected. Basically, the event funnel showed us what part of the product we should be looking to change if we wanted to drive the highest increase in user engagement.

The event funnel is one of the SQL queries I have imprinted in my brain.

To be able to build a funnel, you need to generate a table with one row per step in your funnel, and then a count of the number of users who made it to that step.

These step_name values are analytics events that we're tracking in our app (you can use a tool like Segment or Rudderstack to set up event tracking if you haven't already!)

Once you've figured out the steps that you want in your funnel and the order that you want them in, you can use this SQL template below to build your event funnel. Our team loves seeing these funnels now, it drives a lot of our work. We use Beacon to share the latest event funnel data in our team Slack every morning before stand up.

I tapped out at 3 events, but you can follow the pattern in this template and add more events as additional sub-queries (these are actually called "CTEs") to fulfil your funnel needs!

So here it is, in all its glory: The event funnel.

To run a query using this event funnel, you'll need to make sure you've got a few thing sorted:

Step 1: Plug the right variables into the query below.

The user_id field needs to be the identifier for your users (or the unit that you're counting in the funnel - e.g. team_id if you want to know the rate of conversion for teams doing something)
The event field should be the name of the step that you're referencing in each sub-query (CTE).
The timestamp field should represent the time when the event occurred.
You'll need to change the FROM project_name.dataset_name.event_name_1 to reference the table where your event data is stored for each given step.

I've commented out some code at the bottom which lets you specify a range of dates for the funnel (see: IF YOU WANT TO SPECIFY A RANGE OF DATES, YOU CAN DO THAT HERE). You can add it in if you need it, but it's not required for the query to work! 🙂

WITH event_1 AS (
    SELECT
    user_id, -- identifier of the thing you're counting in your funnel
    'get_in_rocket' AS event, -- name of the step in your funnel
    MIN(timestamp) AS timestamp_first -- timestamp of when the event occurred

    FROM `project_name.dataset_name.event_name_1` -- table where your event data is stored for step 1

    GROUP BY 1, 2
),

event_2 AS (
    SELECT
    s2.user_id,
    'push_button' AS event,
    MIN(timestamp) AS timestamp_first

    FROM `project_name.dataset_name.event_name_2` AS s2

    INNER JOIN event_1 s1 ON s1.user_id = s2.user_id

    WHERE s2.timestamp >= s1.timestamp_first

    GROUP BY 1,2
),

event_3 AS (
    SELECT
    s3.user_id,
    'blastoff' AS event,
    MIN(timestamp) AS timestamp_first

    FROM `project_name.dataset_name.event_name_3` AS s3

    INNER JOIN event_2 s2 ON s2.user_id = s3.user_id

    WHERE s3.timestamp >= s2.timestamp_first

    GROUP BY 1,2
),

all_events AS (
    SELECT CONCAT('01: "', event, '"') as step_name, user_id, timestamp_first FROM event_1
    UNION ALL
    SELECT CONCAT('02: "', event, '"') as step_name, user_id, timestamp_first FROM event_2
    UNION ALL
    SELECT CONCAT('03: "', event, '"') as step_name, user_id, timestamp_first FROM event_3
)

SELECT
step_name,
COUNT(user_id) AS num_users_making_it_to_step,
ROUND(COUNT(user_id) * 100 / (MAX(COUNT(user_id)) OVER(PARTITION BY NULL)), 2) AS percent_of_users_making_it_to_step

FROM all_events
LEFT JOIN event_1 USING(user_id)

-- IF YOU WANT TO SPECIFY A RANGE OF DATES, YOU CAN DO THAT HERE
-- This is the "From" date:
-- WHERE event_1.timestamp_first >= '2020-12-01'

-- This is the "To" date:
-- AND event_1.timestamp_first <= '2020-12-03'

GROUP BY 1
ORDER BY 1 ASC

Step 2: Use Beacon to share the funnel in your favourite Slack channel!

Once you've installed Beacon into your Slack workspace and you've connected to your database, just type /run-query, then your SQL query and hit enter.

Step 3: Save your query so that the rest of your team can use it!

Once your query is posted in Slack, you can hit Save Query to make the SQL query for your event funnel available to everyone else in your team!

And that's it!

Feel free to shoot me a message at katie@gethubble.io if you have any questions or feedback, and go check out Beacon so you can share your nifty new event funnel with your team, directly in Slack 😊

Run SQL in Slack

Katie Hindson — Tue, 24 Nov 2020 16:17:20 +0000

Write SQL in Slack and bring the latest analytics into the conversation.

In my first week at Hubble, a teammate shared a SQL query he'd run in Slack.

Since I'd just joined, I hadn't set myself up with our company's database yet (and had spent a bit too much time getting my dev environment lookin' right 💁‍♀️). So, when I tried to open what he'd shared, it took me ~30 minutes before I could actually see the results.

This got us to talking: how annoying was it that we couldn't just run SQL and share the results straight in Slack?

This was a problem I'd run into before. At least once a week, I'll have to share SQL results with engineers in Slack for debugging, or invest ~ 1 hr of time getting someone set up with BigQuery and understanding the UI just so that they can re-run really specific queries I've written for them.

A few other companies we'd talked to had also mentioned some of their frustrations in quick and easy SQL collaboration. Specifically:

A fitness company wants to make their daily growth metrics visible by all the team each day, so they run SQL queries and copy the outputs to Slack each morning, where they know all team members will see it rather than logging into a BI dashboard.
Another data analyst was trying to collaborate in SQL with their marketing director. They had to do a bunch of copy-pasting of code and sharing screenshots of the SQL output, making it really slow and difficult to actually identify any problems.

All of this got us to thinking: why not bring SQL into Slack? (Because everyone needs a reason to spend more time in Slack, right?)

We built Beacon so you can collaborate on SQL with your team, directly in Slack!

With Beacon, I open Slack and run a query directly in Slack where the output is shared with my team.

Beacon makes the output from any SQL query super accessible to everyone in your team by posting the results right in Slack.

And, collaborating in SQL becomes a breeze because you can save your favourite queries and share them with your team (because we all know, SQL is more fun with friends 👭). All of your saved queries are automatically available to your whole team, so everyone has access to what they need, when they need it, at the click of a button all in Slack.

Try using Beacon to share KPIs, save common queries, and more!

You can install Beacon into your Slack workspace using this link:

Add to Slack

Beacon connects to:

Snowflake
Bigquery
PostgreSQL
Redshift
Rockset

Shoot me a message at katie@gethubble.io if you have any questions or feedback, we'd love to hear from you 😊