.svg)
The Shortcut Way
Focus on Outcomes, not Output
Other project management tools are laser-focused on output: creating tickets, managing them on a board, running them through sprints, and so on. They focus teams on execution, but completely neglect strategy. There's nothing tying the development work back to the company's objectives and goals. This misalignment leads to delayed launches, wasted engineering effort, and missed targets.
Most organizations try to address this by creating OKRs, but the truth is that these objectives are almost always forgotten or worse, ignored. It's not really anyone's fault. The objectives live in one place while the actual development work lives in another - the two are disconnected.
This can lead to misalignment and cause leadership to lose confidence in the teams building the products, while simultaneously causing those building the products to lose sight of how their work meets the needs of their customers and the business.
Shortcut is the only project management tool that lets you connect your company's Objectives (and Key Results) with your team's development work, together in one place. We call this The Shortcut Way, a new methodology that we've spent years researching and developing.
It's a fresh new approach to building products - one that addresses one of the biggest pain points in product development: ensuring everyone in the organization is aligned and driving towards the right objectives.
The Shortcut Way
- Set Objectives from the Top, and Innovate from the Bottom
- Structure Your Team So Everyone's Voice is Heard
- 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)
Set Objectives from the Top, and 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 objectives 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 Objectives, Roadmaps, and detailed Reports inside the tool itself to provide everyone a clear view into the progress of each team's work.
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.
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 Objectives 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 objectives, individual epics, and user stories.
Objectives are high level company goals. They are the big projects that have a big impact on the business. Epics are the smaller parts of Objectives 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.
