.svg)
The Shortcut Way
Introduction
The way teams create software today is fundamentally broken. Their work lives in a vast array of tools, spread out across dozens of Google Chrome tabs - it's a mess. Information (and important context) is lost as communications are done (and decisions are made) in silos within Slack, Google Docs, Confluence, JIRA, and other tools. 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.
At Shortcut, we think there's a better way. We've built a fully integrated hub for teams to plan, manage, and document their work all through one unified experience (with zero context switching). Stories (our version of a ticket) can be 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.
But even with the best tools at their disposal, teams still struggle to move quickly and collaborate well with one another. Even things we've long taken for granted, like how the teams are structured within the organization, can make or break a company.
The Shortcut Way
- Structure Your Team So Everyone's Voice is Heard
- Set Goals From the Top and Innovate from the Bottom
- Ideate Collectively
- Plan and Build Continuously in One Tool
- Maintain a Single Source of Truth
- Create a Culture of User Empathy and Experimentation
- Structure your Work so you can Ship Iteratively
- Ship Often
- Measure Successes and Celebrate Wins (and Failures)
Structure Your Team So Everyone's Voice is Heard
The best products are built when key stakeholders and teams are given equal voice in the development process. Org structure is critical to ensuring this equity. The most effective teams or squads consist of:
- A product manager
- A designer
- 4-8 engineers
But it's not just the makeup of the team that's important, the structure of the entire org has to be considered as well.
At Shortcut, Product Management, Engineering, and Product Design all sit at the same level within the company. This ensures that if a product manager and designer disagree on a particular idea, each has the freedom to raise that concern without worrying about pushback. Only when these teams sit at equal levels can a truly safe space exist for each.
Set Goals from the Top & Innovate from the Bottom
A balance needs to be struck between how much an organization is top-down vs. bottom-up. Getting this wrong can create a directionless org that neither responds to user needs nor acts with any sort of strategy or urgency.
The best organizations have company goals set by senior leaders, while the individual features and roadmaps for each are driven by the individual contributors (ICs) closest to the user. A top-down goal may be about hitting a revenue number or competing in a new space, while the roadmaps and features required to hit that goal may be driven largely by individual Product Managers and their squads.
Too often, senior leaders try to do both, which only ends up making individual teams feel disempowered. Plus, in larger companies, senior leaders can be so far removed from the end user that their feature ideas end up mediocre at best.
To help support senior leaders and ICs in maintaining this balance, Shortcut provides high level Milestones, Roadmaps, and detailed Reports inside the tool itself to provide everyone a clear view into the progress of each team's work:
Ideate Collectively
Too often, Product Managers try to come up with product ideas in a silo. This creates two problems:
- The ideas are limited by that one individual's capacity.
- Getting buy-in from key partners in the development process is more difficult.
This is why many Engineers appear to resent Product Managers. They don't inherently understand the 'why' that led to the product ideas and so don't really care about building them. They're not bought in because no one cared about getting them to buy in.
At Shortcut, we believe in bringing together key stakeholders in Product Management, Product Design, and Engineering as early as possible. Using a simple 1-page 'MVP Ideation' document, this cross-functional team can collaborate on an idea, evolve it to something great, and ensure everyone is on board.
Plan and Build Continuously in One Tool
Teams should plan and build collaboratively, together, in real time.
Too often, we see teams work as if they are in an assembly line: they write a requirements doc, hand that doc over to engineering, wait until it's built, release it, then write a doc for v2 and start the whole cycle anew. This slows down speed-to-market, while keeping any learnings from the development process from making their way into the final release.
Using Shortcut, teams can plan and build continuously and simultaneously. Everyone can jump in and create Stories, assign tasks, connect Epics, and agree on Milestones no matter where they are in the tool. For example, a product manager can turn any text in one of their Docs into a Story, assign that Story to an Engineer, and their original documentation will be kept automatically up-to-date whenever the Engineer updates the Story with the progress on their work.
Maintain a Single Source of Truth
With Shortcut, for the first time, a team's entire product development flow can be stitched together in one tool. We allow teams to directly connect the planning side of their work to the building side. And it's all done seamlessly in one unified user experience.
This unified experience ensures there's only one version of the truth throughout the platform. No matter where anyone updates a Story, the latest version of that information is shown to users in Docs, Epics, Boards, and elsewhere.
Create a Culture of User Empathy and Experimentation
Your team should be meeting with customers regularly (ideally weekly). And you should do your best to spread what you learn throughout the organization, which means you should get cross-functional and bring in engineering, support, sales, marketing - the whole gang. That way, everyone better understands why they're doing what they're doing.
When you meet with customers, don't simply try and understand their problems, build together with them: show them prototypes, show them competitor products, ask them to ideate with you. Do whatever it takes to integrate them into your team's development process. Get creative.
Once you've actually built the thing you're trying to build, you should ensure there's a proper A/B testing platform in place so your team can launch features without fear of hurting the bottom line. Without this platform in place, your team will become more risk-averse and your projects will become larger and larger in scope because there's no mechanism to experiment and ship features iteratively.
Structure your Work so you can Ship Iteratively
It's always helpful to break down a larger project into its component parts so you can ship iteratively and learn along the way. Begin by laying out the actual work needed to get the project shipped, including any high-level milestones, individual epics, and user stories.
Milestones are high level company goals. They are the big projects that have a big impact on the business. Epics are the smaller parts of Milestones that add user value and should be scoped to take a reasonable amount of time (max of 12 weeks). Stories make up Epics and they are the individual units of work for your team. Each Story should not take longer than 2 weeks to complete.
At Shortcut, we usually have teams running 2-week sprints (a.k.a. Iterations), with each sprint containing the necessary Stories that can be completed during that time. Though these teams are shipping their work daily, we expect them to present something meaningful to the rest of the organization at the end of each sprint, showcasing their efforts and celebrating the sprint's success.
Ship Often
Shipping iteratively is great, but we also expect our teams to ship often.
We put any work we're doing behind a feature flag so that we can launch and use it internally as soon as it's ready to play with. This lets us learn about the actual thing we’re building, even as we continually make updates and improvements before we ship the first version to customers.
Once ready, we ship it to our users behind an A/B testing flag so that we can monitor any changes and compare against the existing experience. This ensures we get key data that we can use to iterate and learn on an ongoing basis.
Measure Successes and Celebrate Wins (and Failures)
It's important to establish success metrics before anything is shipped and to remember to reflect back on those metrics once the product has been live for a few weeks. Ask yourselves: was it successful? if so, why? if not, why not?
Being retrospective is critical not only in ensuring your product gets better, but also to ensure your team is continually improving as well. At Shortcut, we always hold retros to reflect on the work after each sprint, release, or issue we encounter. We constantly question ourselves so that we can learn and improve.
And sometimes, we learn that the best course of action is to stop working on a particular feature altogether - and that's okay. If you're going to fail, do it quickly, so you can turn around and focus your efforts on what is working or try out new hypotheses that may work better. Always make sure you're learning so you can continuously improve.
Shortcut is built to support and reinforce all of these principles. Sign up to take a closer look at how we can help you and your team.
