Skip to main content
Automatically keep your work and documentation completely in sync.LearnaboutDocs.

Product Development the Shortcut Way

Shortcut Chief Product Officer
Arman Javaherian

I’ve been working on product teams for close to 20 years now. Over the course of this time, company to company, I’ve seen a lot of similar struggles. In short: right now, building software is simply much harder than it needs to be.

The way most teams create software is fundamentally broken - and it’s not your fault!

It’s because:

  • There are too many tools - you’re expected to plan, document, and build using a vast array of tools. 
    undefined
  • Context is lost and you can’t find what you need - information (and important context) is lost as communications are done (and decisions are made) in silos within Slack, Google Docs, Confluence, JIRA, Notion, and many other tools.
  • There is too much context shifting - everything feels disjointed, and moving between these tools requires intense context switching - wasting precious mental energy that should instead be focused on doing the actual work itself.

To fix this, Shortcut is building a fully integrated system for product and engineering teams to plan, manage, and document their work, all in one unified experience. Shortcut Docs is a big component of this; in fact, it’s part of the very fabric of Shortcut.

In Shortcut, your docs are directly connected to the work you do everyday, and are integrated with everything that you do.

This post explores product development today versus the product development of the future with integrated Docs.

Product Development Today

Product Development

What does product development look like today? Traditionally, it starts with a requirements doc: a PRD, an ideation doc, a design doc, etc., for people to collaborate on. Here’s where the context originates: the user problems, the user Stories, even the Epics which lay out what the project looks like.

The PM, usually with an engineer, will then go in and turn everything in that doc into Stories, tickets, and tasks. This creates a duplicative effect– the same context has now moved from one place to the next.

Once the engineers get to work, they start moving tickets across different parts of the workflow statuses and the workflow. But what happens in the iterative world of product development and software development, is that these engineering teams and the product teams and the designers involved in the process end up making tweaks. They start adding information, adding new data. They’re going to change some of the Stories. They’re going to change some of the core requirements and tasks and tickets - but they’re going to do it where they are. They’re not usually going back into the doc to double key any changes there. They’re actually doing it in the tickets: they’re adding comments and decisions into the tickets itself.

This creates a lot of problems!

All this iterating and making decisions on the fly, updating Stories without updating the actual doc, results in dead docs with teams who no longer trust them.

Over my career, I’ve seen it time and time again: people stop referring back to the doc, because all it takes is one requirement, one decision, one comment, one change to happen in the ticket, and people are now referring to, and trying to find that ticket because it now has the most relevant information, i.e.: what is the the latest heading for this feature? What does the latest design look like for that feature?

When people start ignoring a doc, the doc becomes obsolete. This is a huge problem for a software development organization when you're trying to make sure that people have the right context for what they're building.

Once docs are ignored, the only way to find context is by stitching together all the different tickets in the actual building environment. It’s inevitable that teams start losing critical context. Then it starts over again with V2 and V3 of the feature, with a PM creating V2 and V3 docs, all ending up with a bloat of documentation.

So, what’s to be done? Everyone knows they need good documentation, but it’s impossible to achieve it in the current way people are working. This is the core problem that we're solving with Shortcut Docs.

Product Development in Shortcut using Docs

Shortcut Product Development

We created Docs because we believe that fresh, living documentation updated in real-time is the only kind that provides trustworthy, useful written information when it comes to collaborating and building great products.

Shortcut Docs is an integral part of Shortcut. Stories, Epics, and Tasks are fully integrated with Docs, so that as work gets done, everything is updated automatically. There is no wasteful duplication. There's no double keying. It’s one source of truth to find the most current, relevant context and information.

Docs creates a very harmonious kind of system that allows documentation to be relevant, cross-functional, trusted, and living going forward.

For example, you can highlight any text in a Doc and create a Story from that text to be forever synced across Shortcut. This way, if an engineer updates that Story while they're working in the code, it automatically updates in Docs. You can also link Docs to Epics, Milestones, Labels, and Iterations.

We think Docs is a game changer for product development.

Check out the video below to see how it works.

The Shortcut Way: Try it for Free

We’ve seen thousands of companies and how they build software. Therefore, we have opinions about how to build software that we’ve built from watching those thousands of teams.

At Shortcut, we believe in a fully integrated hub for teams to plan, manage, and document their work all through one unified experience (with zero context switching). Stories are fully embedded on boards, documents, roadmaps, reports, and milestones throughout the product. Any updates made to that core unit of work is automatically reflected everywhere for all to see, both internally and externally through our dozens of integrations.

We believe these tenets are more essential for productive work:

  • Structure your team so that all voices are heard
  • Set goals from the top and innovate across
  • Ideate collectively
  • Plan and build continuously in one tool
  • Maintain a single source of truth
  • Create a culture of experimentation
  • Structure your work so you have ship iteratively
  • Ship often 
  • Measure successes and celebrate wins (& failures)

To learn more about the Shortcut Way, read the full manifesto.

Our goal for Shortcut is to be the most enjoyable, efficient, and powerful way for you to get stuff done. To try it for yourself or for your team, sign up for a free trial.

Topics:

More stories from Shortcut