1, 7, 30, 365 Days: A Framework

I’ve talked to various folks developing this idea, but I haven’t written it down until now.

A Framework for Product Engagement

In the developer experience arena, I hear lots of people talking about “day 1” and “day 2 operations”. Day 1 is meant to mean the initial green-field development experience before the application goes into production, while day 2 is the process of continuing to push improvements to the software after release. I have a couple gripes about this framework:

• It’s horribly simplified. It suggests there’s a single transition, from “building” to “running”, and that transition happens once and then the world is forever changed. All frameworks are reductive, but day 1 and 2 is a step too far for me.
• The timelines are horribly unrealistic. “So what”, you say, “everyone knows what they mean”. The problem is, I’m not sure that’s true. If you’ve an engineer, you’ve certainly heard of the PM or stakeholder with an unreasonable idea of how long it will take to move a concept to production. “Day 1” and “Day 2” perpetuate that unreasonable idea that a team of 8 or 10 people can become productive immediately with a new tool (or even an existing tool and process, but a new goal).

My Alternative

I’d suggest breaking product engagement down into four arcs or stories. Not every user will go through all of these – if you’re familiar with a marketing funnel, this is that in action. Some users might also manage to skip or accelerate some of these phases, but most of them will need most of these phases.

The following is written from the perspective of a user adopting a product, following their phases of adoption.

Day 1: Exploring

On day 1 with a product, you’ve just heard of it, or you’re just investigating it for the first time to see if it will solve a problem for you. You’re possibly evaluating several different products, or you’re looking a new product to see if it will fit with your existing tools and processes. (Everyone has some existing baggage, so day 1 with a dashboard is different from day 1 with an IDE, or day 1 with a source control system…)

Most users will go through “day 1” with anywhere between a half-dozen and twenty products in a year.

On day 1, you’re is trying to figure out the answer to the question:

Is this tool the right tool for what I’m doing?

You may look at a bunch of different resources to figure that out, but you probably have a time-box. I’d generally estimate somewhere between 1 and 4 hours all-told. This starts with a name, and probably a Google Search. If you’re lucky, you’ll find the home page and some carefully-crafted marketing documentation. If you’re lucky, that page won’t just explain how transformative the product is, but what the product actually does, and how it works so that you can figure out if it matches the problem you have.

Some of the resources you might look at during Day 1:

• Marketing copy. You’re interested – hopefully the text and content will keep you interested and lead you through the product features.
• Documentation. Assuming that the marketing page just gives a high-level gloss, you might dive in here to understand how things work, or if it can connect with the tools that you already use. Personally, I tend to try to look for APIs, to see how the product “sees the world” under the covers.
• A live trial. If they have something like Katakoda available, you might open up a browser window to try things out. You probably don’t want to download a CLI or install software locally yet – you’re gathering information before you make that leap.
• Video explanations. You might get this from the product site, from YouTube, or from a livestream. If they have good video content on the marketing page, you might watch that, but you might also look for an independent point of view.
• Blogs or third-party content. Sometimes, you want to know what it’s really like, and the best people to answer are the ones who actually use the software. It’s easy to tell good stories about yourself, but the stories other people tell about the product – those are the most interesting.

Note that at this stage, you aren’t very committed – you’re considering the project, but it’s more of a speed-date than a lasting relationship. If they’re convincing, you’ll choose the product, and move on to…

Day 7: Building

Congrats, you’ve gotten past day 1, and you’ve decided to take a bet on this! You’ve downloaded any needed tools, followed the quickstart or tutorials, and are starting to build out a demo to convince the rest of your team. It’s possible in some cases that you might manage to skip this phase, but most of the time, there’s a short little honeymoon where you and the tool have a nice little relationship, one-on-one, with no one else to mess things up.

At this stage, there’s a little more commitment – you’re probably willing to sign up for an account, download a CLI, or install a service locally, depending on the application model. You’re still not sure whether this is going to be a long term thing – it will depend on how well the larger group adopts the tool. Gentle support and check-ins at this stage feel appropriate, but probably not a pushy sales process, unless that’s what you expect from all the companies.

I’m building something small… let’s see how it goes.

Work at this stage is generally solo – whether it’s a process tool, a development aid, or an authoring tool, you’re still getting the hang of it, and don’t have anyone to work with yet. What you need:

• Easy getting started. This might be tutorials, in app-guides, a simple (or progressive) UX, templates, or other scaffolds. You don’t yet know what “good” or “normal” looks like, and you’re not sure if you’re holding the tool right.
• Rapid feedback. Again, since you aren’t quiet sure what to expect, quick clear feedback is critical. Opaque error messages or non-actionable hints are be extra-frustrating, as they send you down a rabbit hole trying to figure out what to do.
• Support and community. Sometimes, you just need to figure things out with another human being. Stack Overflow, Wikis, Slack, Forums, and Discourse are all great ways to learn from more experienced users.

The end of the “day 7” period is when you have gotten enough value out of the tool that you feel ready to advocate for it to other people in your group or organization. With that, you’re on to…

Day 30: Building Together

Day 30 is when the team or organization has adopted the tool. Everyone is using it, and they’re collaborating with it in some way. If it’s a software development tool, they’re deploying to shared staging and production environments as well as development environments. If it’s a process tool like Jira or PagerDuty, multiple people are working on the same issues and assigning work to each other. If it’s a communication tool like Coda or Miro, people are sending each other links to documents and sharing insights through the tool.

This is awesome. If day 7 was the honeymoon with that just you, now you’ve got a whole party going! Your team loves the tool enough that they can see the value, and they’re doing more together than they could before. It’s pretty great. At the same time, some of the stuff that you used on day 1 and day 7 starts to wear a little thin. A quickstart environment that disappears after 2 or even 48 hours isn’t really a place to run staging or production, and rapid feedback is great until you start seeing the feedback of someone else’s deployment that happened to stomp on yours.

This is how our team builds things.

The team needs a bit more structure and tools to support their shared interaction. What those tools are depends on the product, but a few common examples are:

• Access controls. When you’re working on your own, access controls just slow you down. In a small group, you can get by with a bit of trust. As the group gets larger, the chance of someone accidentally hitting Delete Project starts to keep you up at night. That’s where access controls come in.
• Multiple Environments. For software projects, this might be development vs staging vs production. For communication, it might be “project A vs project B”. In any case, once you get a big enough party, you need some way to split things up so that people can have a conversation without being drowned out by the group next door.
• Process and previews. This isn’t a paean to change control processes or bureaucracy; without tools to understand how an environment is going to be changed, and possibly even preview the result, teammates start to feel “who moved my cheese” as people work the tool against each other.
• Billing and group management. If it’s a free product, billing may not be a problem, but there’s probably some problem about “who’s allowed to do what” that’s a bit related. Bonus points here if you can tie into existing systems like OpenID Connect.

After some time building together, the tool has been solidly adopted into the organization. That’s great, you’ve won and created lasting change! And now, you and the tool need to own it on…

Day 365: Customers!

On day 365, your own work has flowered! You’ve launched a product, and your customers are excited and using your product. Maybe some of them have even reached day 30 or 365 on your product – this is the last step on the road.

And the last step on the road is that you’re depending on this tool for your business and customers. You may have critical requirements that are written into law or regulation, and because you depend on the tool, you need the tool to help you meet those needs. These needs are totally unlike the ones you faced on day 1 or day 7, though most of the day 30 needs are still there, and still urgent.

My customers depend on this, and when it breaks, it’s my problem.

Still, on day 365, the needs start to look like enterprise needs:

• Audit logs. It’s not enough to trust that only the right people have access. You also want to be able to check that the right people are doing the right things.
• Accreditations. It might be PCI-DSS (credit cards), HIPAA (US health care), GDPR (EU data privacy), FIPS (US govt), or something else. Penalties can include fractions of global revenue or executives put in jail, so you need to need to care about how the tool fits into your corporate compliance picture.
• Backup and restore. On day 30, “I deleted the production database” is annoying, but on day 365 it’s a critical failure. Disaster recovery mechanisms (ideally, tested) are a must-have – your livelihood is depending on the tool.
• Consistency. I wouldn’t think I’d need to write this, but this week I need to figure out how to switch my Google Workspace domain back to the “free for families” tier from the “pay $30/month or grandma’s email gets it”. This type of back-and-forth behavior is corrosive and kills trust. It’s going to take a lot for me to invest my own time in learning another Google product unless I can see why they won’t turn around and put me through the wringer in 1-4 years time.

That’s Great. What Do I Do With This?

I’m not a product person by background, but this is sort of a product discussion. My main goal here is to give vocabulary to the different parts of the total product lifecycle, so I can reference it in later discussions. i.e. when talking about a “hands on lab” environment at work, I can point out that it’s an addition to our “day 1” experience and might help someone on day 7 sell the idea to a skeptical colleague who’s still at day 1. I can also look at some of the other options in that area, and ask whether we have sufficient video content to justify the expense of building a live try-it-out space.

We can also talk better about how product features might be great at certain phases of the product experience, but a problem in others. What actually put this into my head at first was a realization during the early (0.2?) days of Knative – Knative Build was great for getting started, but having the “how to build the container” definition in the Service definition had a bit too much runway. You could see how you could start adding unit tests, and maybe some integration tests for the service into the build and failing the build process if the tests didn’t pass. That was pretty cool.

But then you start to think about what things look like on day 30 and attempting to push multiple containers, and you realize that you’re going to need to reach for a different CI tool like Jenkins or Concourse (Tekton was born from Knative Build, so it didn’t exist yet). All of a sudden, we’ve led people on an attractive path from day 1 to day 7, and at day 30, we tell them to throw away all the path we’ve built up to this point, and to start on a new day 1 journey. That didn’t feel so great, and neither did the idea that on day 365 people might be building new artifacts for production which were different from the artifacts that were tested (even if it was just re-running the same pipeline). Cloud Foundry did this, and it always felt like a weak spot where we hoped to do better.

So, with tears in our eyes, we moved the build specification out of Knative Services, and shortly thereafter they moved out of the project entirely in favor of the CDF and Tekton. I think it was the right call overall, but that early “miss” in this model meant that it took a couple years before a functions effort finally had the infrastructure needed to get off the ground again.

That’s about it. Hope this was a fun and entertaining tour through my thought process around building great software products.