Over 200 million people worldwide use Microsoft Sharepoint as a content service platform, 

Did you know you can easily embed ("build in") a ShiftX flow in your Sharepoint document and both read and edit the flow from Sharepoint? 

You add your ShiftX flow in Sharepoint by embedding it through an iframe (If you don't care about the technical details, watch the "how-to" video at the top of this post). 

As Sharepoint supports iframe (which stands for "inline frame"), we can embed a ShiftX flow through the iframe HTML tag that can look like this:

You're free to adjust the width, height, and frame border to adjust the presentation on the page. 

If you're ready to embed a ShiftX flow in your Sharepoint document, you need the embed code to the specific flow you want to embed. 

You'll find the embed code to your ShiftX flow behind the "share" button in the top-right corner of your flow dashboard. If you've enabled access control, you'll see the following options:

Here, you need to expand the "share on other services" drop-down and click "Copy embed code." Then you'll have the correct embedding code in your clipboard, and you're ready to add it to your Sharepoint document. 

Still a bit unsure how to do it? Maybe the "how-to" video at the top of our post here can help. If you're still stuck, feel free to 

How to use ShiftX in Sharepoint

Digitalization, innovation, streamlining, and change management. It's all about processes and making people and systems interact in new ways. But before you can change and get to a level of continuous improvement, you got to involve the people doing the work.


While ShiftX Co-Founders Nikolai Strandskogen, Eigil Sagafos, and Kjetil Jortveit worked as consultants in design and tech agencies in Norway, they noticed that the client story often repeated itself. In most cases, clients ask consultants to assist them with their projects.

As the onboarding process begins, the consultants would want to understand today's as-is situation. The answer often lies in fragments within different departments of the client. And so the over-enthusiastic and chaotic workshops begin.

There has to be a better way of getting an accurate picture of the company's current state?

Watch the webinar to learn more about the birth of ShiftX, and how the involvement of employees is key to continuous improvement and change. 

Webinar: Why involving 10x more people is key to continuous improvement and change

How should you organize your work when you want to build a digital product as fast, painless, and right for the customer as possible? 

The question is old and has many answers. 

Several of us in the product team here at ShiftX has been working in consultancies for many years and have met both the positive and negative sides of frameworks like Scrum and Kanban.

And while these classic frameworks might work in bigger companies, we wanted a framework that made the product team feel more ownership. We want to hire people who love solving problems and are passionate about building quality products, and not just turning tickets.

not spending enough time digging into the real problems

While developing, we also started questioning our own decisions: 

Were there other more important features than the ones we decided to make? Did we find the wrong solution for this feature?

We also saw that it was hard for the rest of the company, the ones working in admin and commercialization, to understand why we did what we did. 

When we got feature requests and bug reports from customers, it was hard for people outside the product team to understand why we didn't make or fix them immediately. 

The answer was clear for us. In a startup like our own, where there's an endless list of features we want to create, with a relatively small team (we're about 3-4 people working full time with product development), we need to prioritize hard.

Our solution has been to mold our version of 

the Basecamp-created framework called Shape Up

So, at the core of Shape Up lies a premise of "betting": 

Given what you know at this exact time, what feature (that can be made in a realistic amount of time, with a realistic amount of people) do you bet on to improve your product the most for existing and potential users?

You align the product team and the whole company, with bets taken on which improvements matter the most for you, right now. And when the decisions are made, everyone knows this is what the product team is focusing on solving. 

Each "Shape Up cycle" is run in six weeks. And the setup of every cycle looks the same:

Everyone in ShiftX can suggest ideas for implementation. This is nice, both for making the whole company feel ownership and making it evident that when we get 20-30 ideas, everyone understands we can't make them all at once. It's about prioritization. 

Often the ideas are based on customer feedback (

, our customers can give us product feedback directly) or our long-term roadmap. Before every cycle, we collect ideas in 

 before we move over to the shaping phase. 

At the start of each new cycle, the product management team hold a meeting where we decide what ideas we want to dig deeper into. This is the first point of prioritization. 

How many ideas we pick for shaping in each cycle depends on how many people we have available for working with them. But it can be anything from 1 to 4 ideas. 

The owner of every idea that gets chosen for shaping then gets one week to write a pitch, with a description of the problem and a suggestion for a solution.

After the shaping week, we sit down with the product management team and go through all the pitches. Our product management team consists of people with different responsibilities, from product, commercialization, and strategy. Out of the pitches, we pick the one or two idea(s) we believe to be the most important for our users and for pulling us in the right direction following our roadmap. 

This is where we create the features we've decided to make. And even though the ideas have been shaped the previous week, the team implementing the feature still has a lot of autonomous thinking and problem solving to do. That's a central part – we're leaving independent thinking and problem solving to our product people, and they feel ownership in return. 

What's also important to note here is the strict timeboxing. Not done in your given four weeks? Too bad! Ship what you've got (if it's working fine), and create a new idea for further developing the feature in the next cycle. 

"So, what about all the bugs and smaller fixes that constantly pop up? Don't you fix them?" 

Yeah, we know. Bugs appear when they want to. And obviously, we do take some minutes here and there for some minor fixes. But nothing (almost) is so important, it can't wait for a week or two. If you zoom out, the bug someone just discovered has probably already been there for a month. It doesn't matter (to the very large majority of the world) if it stays there a couple of more weeks. 

We are now (more) sure about our decisions after each phase. If we made the wrong decision, we time-boxed it to 6 weeks, and we also learned a lot. No biggie. 

Make the feature (or at least a shippable part of it) fit inside 2 or 4 weeks. It makes us not think too far ahead.

Easier for the company to follow the cycle and what we are making

Easier for the company to raise their voices on what we should make

Read Ryan Singers' full version of the book Shape Up

How we build ShiftX using the Shape Up framework

Our product and ideology

Why ShiftX

How our customers use ShiftX

User stories

Keep up with the development

Changelog

Articles for help and inspiration

Support

Product

Product and company updates

Blog

See some typical use cases

Flow examples

Resources

Pricing

The people building ShiftX

About us

See our open positions

Careers

Get in touch!

Contact

Company

 Read more and see available positions ->

In this webinar, you will hear about how Skuld is:

building a continuous improvement culture 

utilizing digital tools in combination with knowledge and experience

managing and getting people involved in the process work 

and why did they chose ShiftX as their new process tool to work with continuous improvement 


This webinar is part of our webinar series where we invite users and customers of ShiftX to talk about different topics related to continuous improvement, business processes, and innovation. 

Webinar: Continuous improvement through employee inclusion

How to use ShiftX in Sharepoint

Webinar: Why involving 10x more people is key to continuous improvement and change

How we build ShiftX using the Shape Up framework