Skip to content

Commit

Permalink
Merge branch 'master' into error-map
Browse files Browse the repository at this point in the history
* master: (41 commits)
  chore(release): Publish
  fix(gatsby): Normalize paths for run queries before caching (#14910)
  chore(release): Publish
  fix(gatsby-cli): add missing node-fetch dependency (#14908)
  feat(blog): Site Showcase Validator blogpost (#14855)
  chore(gatsby-remark-graphviz): add --ignore for test directory (#14906)
  fix(tutorials): rename "advanced" to "additional (#14847)
  fix(starters): update gatsby monorepo (#14886)
  chore(starters): Switch to useStaticQuery (#14857)
  chore(release): Publish
  Add status bar to bottom of screen during develop (#14874)
  chore(release): Publish
  fix(*): fix gatsby-cli dep in source-filesystem & plugin-sharp (#14881)
  docs(www): 25 Workflows - Embedding components in Markdown with MDX (#14543)
  docs(blog): add case study blog post for The Couch / Prima (#14871)
  docs(www): 25 Workflows - Adding CSS and/or Sass (#14779)
  fix(gatsby-transformer-react-docgen): always create description nodes (#14876)
  chore(release): Publish
  chore(gatsby): revert progressbar functionality (#14884)
  Revised "winning over engineering leaders" Docs page (#14830)
  ...
  • Loading branch information
m-allanson committed Jun 19, 2019
2 parents 423a281 + 7994c1d commit 1dd4df0
Show file tree
Hide file tree
Showing 157 changed files with 2,312 additions and 893 deletions.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
88 changes: 88 additions & 0 deletions docs/blog/2019-06-17-product-management-at-Gatsby/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
---
title: "Product Management at Gatsby"
date: 2019-06-17
author: Marisa Morby
excerpt: "In this post I outline the high level tasks and goals of product managers at Gatsby"
tags:
- product management
---

Our goal with product management at Gatsby is to create an ongoing and iterative product discovery and development process that allows us to ship customer value quickly and with confidence in our product–market fit. There are a lot of ways to break down product development and management.

The first is “waterfall” development where information is generated at the “top” of the company and then slowly (or quickly) trickles down to the rest of the organization for execution.

Alternatively, there is the “agile” approach that focuses on small teams making fast decisions and moving quickly.

At Gatsby, we want to ensure we’re aligned around business objectives set at the company level, while also bringing research, design, and engineering into the product development process early so that everyone has the context they need to succeed. We also want to encourage everyone at Gatsby to experiment, make mistakes, and [tinker with ideas](https://breakingsmart.com/en/season-1/tinkering-versus-goals/).

## What is the product manager responsible for?

Ultimately the product manager is responsible for “evaluating opportunities and determining what gets built and delivered to customers” (Marty Cagan, [Inspired: How to Create Tech Product Customers Love](https://svpg.com/inspired-how-to-create-products-customers-love/)).

The best way to do that is by **creating a prioritized backlog of ideas that are worth building, prioritizing that work, and collecting customer feedback for action**.

This then becomes a cycle that we can rely on to constantly feed us with new ideas. But this is where it gets more complicated.

## How will we generate ideas for a backlog?

There are a few ways product managers can start generating ideas for their backlog. We’re not going to talk about the specific process in this post, but rather the model we want to follow to help us generate a backlog.

### Discovery research

Discovery research is focused on talking with current or past customers about their experiences with a product or workflow that your product has. This type of research helps you understand the needs of the customer, get an understanding of what’s working for them now, and get a list of problems they’re having.

The product manager needs to have enough context of the landscape to decide which of these problems are critical for solving and work with the team to create acceptance criteria that solves the problems we’re trying to address.

Many times, it might be helpful to have a visual concept to show stakeholders to get them interested and bought into larger pieces of work. This can be a presentation deck with market research interviews, relevant data, or customer interviews.

At Gatsby, we often use a type of Jobs to Be Done discovery work. We talk with people who we’ve identified as our potential customer base to get a good understanding of their day-to-day needs, pain points, and workflows. By doing that, we’re able to understand common patterns across companies and large areas of frustration that we can address with our products.

### Feasibility research and prototyping

Prototyping can be done by product managers, designers, engineering, or anyone with context on the problem we’re trying to solve and outcome we’re trying to achieve. The goal of prototyping is to show someone how to solve a complex problem, rather than trying to only explain it to them.

The product manager is responsible for making it clear that there is prioritized work available for technical feasibility research or prototyping when initial discovery shows that an idea is worth pursuing. It’s important to do this as early as possible so that engineering is involved in the ideation. This helps the team make better decisions about whether or not the feature or product impact is worth the cost to create. Doing this research early helps avoid wasted time and money pursuing ideas that aren’t actually reasonable to build.

Feasibility research helps you decide if it’s possible to make and what the cost will be in terms of time and resourcing.

Both feasibility research and prototyping are used internally to create context and help with understanding outcomes, risks, and needs for upcoming work.

Recently we've used prototyping with our current build updates. By prototyping the functionality on a small scale, we can use the updated build process internally and identify any immediate issues or errors much more quickly.

### Proof of concept work

A proof of concept is closer to a high-fidelity, workable prototype that is meant to be customer-facing. It works within your product, looks like it belongs there, and collects data. A workable proof of concept helps reduce the time to ship because you can try it out with reference customers or do a small rollout to a portion of your customer base.

We initially did proof of concept work with Gatsby Preview in its alpha phase. The functionality existed, and we were sharing it with people, but it was a small group of testers who helped us find what worked well and what needed to improve so that we could continue making the product better.

## How will we know what to work on?

At Gatsby, we wanted to make sure we had a way to look at work from a macro to micro level. Doing this made sure we had higher visibility for our work.

### Wardley mapping

We use [Wardley mapping](https://www.cio.co.uk/it-strategy/introduction-wardley-value-chain-mapping-3604565/) to think through the strategic value of a product and give us a high level picture of where we want to go. Wardley maps are like topographical maps for your business or product. You’re able to see the current landscape and map out where your product currently is, as well as plot how it will evolve over time as the business and product landscape changes.

We’ve had working sessions where we will complete Wardley maps as a team around product ideas, or existing products that we are interested in evolving. Wardley maps help us create shared context with our product, design, and engineering teams so that we understand where we currently are and where we’re trying to go with the product.

### Intent mapping

Our Principal Product Manager, [Preston So](@prestonso) introduced us to intent mapping as a way to set priorities and dependencies for major pieces of product work over the next 3 - 6 months. It’s a way to let all the teams have one source of truth for what we want to focus on in the medium-term.

Acceptance criteria listed in the intent maps helps explain what we are going to build and why. We don’t create anything without a reason, and always bring the team in to collaborate on acceptance criteria.

### Objectives and Key Results

Objectives and Key Results (OKRs) are specific metrics or outcomes we want to see within the next 1 - 2 quarters. We use OKRs to stay focused on what we’re trying to achieve in the short term. Our OKRs are typically very metric driven, so that it's easy to know whether or not we've achieved our goal. You can read more about OKRs at Gatsby [here](https://www.gatsbyjs.org/blog/2019-04-03-how-we-think-about-product-at-gatsby/).

## How we’ll get product feedback

One of the additional benefits of creating proof of concept work is that you'll have something to share with reference customers as you figure out the best way to solve your biggest customer problems. Reference customers are current paying customers that have agreed to try out proofs of concept, prototypes, or alpha products to help us decide if what we’re creating has product-market fit and adds value.

It’s up to the product manager to have ongoing interviews with reference customers, and to understand whether or not the proof of concept adds value for them.

At Gatsby, we get product feedback from lots of great sources: usability research, data analysis, customer support, pre-customer calls, and customer calls. We’re always excited to talk with people that are using or interested in using Gatsby, and doing this consistently has helped us validate ideas and surfaced new challenges to tackle.

## What will product management look like in the future at Gatsby?

Gatsby is growing fast and we have a few main Key Progress Indicators (KPIs) that we want to stay focused on in the next year. Product management will probably shift and grow as Gatsby shifts and grows. But even as things change, we will always want to focus on reaching out to customers, understanding important problems, and providing solutions for those problems. Our focus should always be to add value and excitement for our current (and future) Gatsby customers and community members.
30 changes: 30 additions & 0 deletions docs/blog/2019-06-17-site-showcase-validator/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
---
title: Maintaining the Site Showcase with GitHub Actions and the Gatsby Site Showcase Validator
date: 2019-06-17
author: Benjamin Lannon
excerpt: "Keeping the longevity of the Site Showcase strong is to continue bring in exciting sites that use Gatsby, but as well to keep our existing showcase up to date."
tags:
- github
---

Gatsby has rapidly been growing in the market of website generators. As such, the core team developed the Gatsby Site Showcase to present a variety of websites using Gatsby. As the showcase grew to include hundreds of sites, long term maintenance would help strengthen the showcase.

## Why a validator

As with most websites, nothing is constant. Designs and even frameworks that companies and developers use to build sites will evolve and change over time. With that, it would be diligent to make sure that Gatsby’s showcase is kept updated and all sites in the showcase are still using Gatsby. Doing this by hand would become unmaintainable as more and more sites were added; automating the workflow would relieve the burden for such an important task.

## Creating the validator

At its core, the validator is a script written in NodeJS that examines every site in the site showcase and first checks if the site is up. It then examines the HTML for key identifiers that point out that the site is written with Gatsby.

All Gatsby sites by default have a container element with the `___gatsby` id as an attribute, which is where the React app will be mounted to when Gatsby rehydrates on client load.

With such, an HTTP request can be done to grab the initial HTML of the page. Then it can examine the DOM using [cheerio](https://github.com/cheeriojs/cheerio), a jQuery-like DOM parser designed for the server. If it is able to find the Gatsby root container, it will continue on to the next site. If not, it marks down the site and will fail the validator upon completion.

For deployment, we decided upon [GitHub Actions](https://github.com/features/actions) which allows for a script like the validator to live inside the Gatsby Git repository and be run on a daily schedule on GitHub’s servers rather than needing to spin up separate infrastructure for the script.

## Benefits and moving forward

The validator was merged into Gatsby Core in late May and it has brought a sense of security as more entries are accepted into the Site Showcase. Core maintainers can check the validator and then if the validator finds sites no longer using Gatsby, we can contact maintainers and clarify if it was their intention.

In the future, the validator can be extended and composed with other tools to better inform maintainers of outliers and how we can keep the showcase and other platforms in check.
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
title: How The Couch Builds Websites in Half the Time with Gatsby
date: 2019-06-19
author: Linda Watkins
tags:
- case study
- case-studies
- ecommerce
- content-mesh
- developer experience
- hosting
- performance
---

![The homepage of thecouch.nyc showing a blue background with the message, "The Couch is a digital studio that makes weird and wonderful things for the internet."](./thecouch-nyc.png)

We recently spoke with Kevin Green, Co-founder and Lead Engineer at [The Couch](https://thecouch.nyc), about how Gatsby helps them speed up their workflow and offer their clients fast, feature-rich sites with extremely low hosting costs.

## About The Couch

The Couch is a team of three designers and one developer that specializes in e-commerce projects for clients like [Clare](https://www.clare.com) and [Dims](https://www.dimshome.com). Kevin, The Couch’s developer and technical co-founder, is passionate about the headless ecosystem and the way it enables him to select the perfect tools for each project. One of Kevin’s favorite tools has been [Gatsby](/) because it makes it so easy to combine data from a variety of headless services into his projects.

<Pullquote>
I like to deliver the best possible solution for a client’s needs and Gatsby is a tool that is tried-and-true for me.
</Pullquote>

## Why Gatsby is Perfect for Prima

When [Prima](https://www.prima.co), an L.A.-based Cannabidiol (CBD) oil company, chose The Couch for their new site, their focus was on providing educational materials to their customers to help them better understand CBD. In addition to e-commerce, the site would need to include extensive written content and imagery, including 40 pre-written articles, a glossary, and a recipe collection.

<Pullquote>
They came to us with a flood of content—something we’re not really that used to.
</Pullquote>

![The homepage of prima.co showing a young woman holding a bottle of CBD oil next to the message, "Welcome to the uprising rooted in hemp, heart, and real science."](./prima-co.png)

Faced with a content-heavy project, Kevin considered his options. Rather than entrusting Prima’s content to a monolithic CMS—and risk slow loading times and an unhappy development experience—Kevin’s thoughts turned to a more modern solution: “Knowing this was going to be a super content- and image-heavy site, I wanted to build it static from the get-go.” By serving Prima’s content as static HTML, Kevin knew he would dramatically reduce the site’s loading time. His positive experiences with Gatsby on three previous production sites made him confident that it was the right tool for the job: “It’s hard for me to go any other route at this point. If I can go static, I’m always going to go static, and Gatsby’s going to be one of my top choices indefinitely.”

## Cutting Developer Time in Half

After years of building projects with traditional tools like Docker and WordPress, Kevin experienced a dramatic productivity boost after switching to Gatsby and the headless ecosystem. Using Gatsby and a combination of various microservices, Kevin can now build sites with complex functionality in half the time he used to: “I built a large system with countless modules, multiple content models and search functionality that’s already prepped for e-commerce...that’s something that used to take me double the time.”

<Pullquote>
From my perspective, Gatsby is an invaluable tool.
</Pullquote>

By embracing Gatsby and headless services, Kevin can now more easily adjust his tools to each project’s needs. To manage Prima’s content, Kevin opted for [Sanity](https://www.sanity.io), a headless CMS which can be connected to a Gatsby site using the [gatsby-source-sanity](/packages/gatsby-source-sanity/) plugin. Prima’s e-commerce functionality is powered by [Shopify](https://www.shopify.com) (integrated with Gatsby using the [gatsby-source-shopify](/packages/gatsby-source-shopify/) plugin). Kevin credits the ease of pulling data from headless services like these into Gatsby with the bulk of his new development speed:

<Pullquote>
I’ve set up Contentful, Prismic and Sanity in so many ways that I can now set up the whole backend and data architecture in a day...It’s a testament to those tools and how powerful they’re becoming.
</Pullquote>

## Inexpensive Hosting

Kevin told us his clients are extremely happy with the lower hosting and CMS costs that Gatsby projects make possible. Since Gatsby sites load as static assets, they can be hosted cheaply (or for free!) by hosts like [Netlify](https://www.netlify.com) and deployed straight to a global CDN. After years of serving sites on expensive hosting, this is a major relief to Kevin and his clients: “They’re getting a ton of traffic and it’s costing them practically nothing,” Kevin told us. “To me, one of the biggest selling points is not putting a site on Heroku and having that cost thousands of dollars a month when people start going to it.”

Prima’s CMS costs are also lower than normal because Gatsby pulls all of their content from Sanity and includes it in the site’s static HTML at build time. This means that instead of having Sanity resend their content every time a user visits the site, Prima only pulls their content when the site is rebuilt. This significantly speeds up Prima’s loading time and reduces their use of the Sanity API.

<Pullquote>
Being able to work in platforms like Gatsby is a breath of fresh air and allows me to control my environment and build beautiful websites that are super fast and inexpensive to run, which obviously our clients also love.
</Pullquote>

## Fast Site, Happy Client

The Prima launch was a big success and the site is now enjoying healthy traffic and organic growth thanks to enthusiastic supporters on social media: “They were thrilled. They’ve gotten a super warm reception,” Kevin reported. In particular, users have noticed that “the site is super fast and the experience is really smooth”—no small feat for a content-heavy site like Prima’s.

After initially launching with its educational content only, Prima’s product line has been added to the site this spring, powered by Gatsby’s e-commerce integration with Shopify.

<Pullquote>
It’s less a conversation about the tools; it’s about whether they do the best job they possibly can for the client. And in the case of Gatsby, it’s continued to do that for me. The sites that we build are fast by default, rendered statically, and don’t cost our clients a lot of money; it’s hard for me to go any other route.
</Pullquote>

To discover if Gatsby is right for your next project, [learn more here](/).
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
4 changes: 4 additions & 0 deletions docs/blog/author.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -308,3 +308,7 @@
bio: "Distributed Systems consultant, Clojure enthusiast, bicycle tourer"
avatar: avatars/anthony-marcar.jpg
twitter: "@Moocar"
- id: Benjamin Lannon
bio: Web Developer, Open Source advocate, new tech explorer - https://lannonbr.com/
avatar: avatars/benjamin-lannon.jpg
twitter: "@lannonbr"
Binary file added docs/blog/avatars/benjamin-lannon.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading

0 comments on commit 1dd4df0

Please sign in to comment.