Att göra agilt eller att vara agil

Date : 17 augusti, 2018

Det är lätt att glömma bort det agila manifestet och bara köra på. Man går igenom dagen med standup, sprintplanering, demo och retrospektiv, men man funderar inte så mycket på om man bara gör agilt eller om vi också är agila.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

När vi har stand up meeting, pratar var och en till teamet som helhet, eller är det bara en rapportering av timmar till projektledaren? Är vi slavar under vårt projektledningsverktyg, matar vi in timmar för att verktyget behöver det eller för att timmarna hjälper oss att utveckla det bästa systemet?

Ibland är dokumentation till stor hjälp. Särskilt när det gäller någon sorts överlämning, inom projektet eller att vi producerat ett API som någon annan skall konsumera. Jag har skrivit dokumentation som ingen någonsin kommer läsa, bara för att projektet haft det som krav på sig. Enligt Lean, är inte det enbart waste?

Jag hade en gammal kollega som ombads att skriva ett sådant dokument. Han plitade ut en innehållsförteckning och fyllde rubrikerna med Lorem Ipsum-text, och påstod att det aldrig upptäcktes. Det kanske upptäcktes den dag han lämnat projektet och de behövde veta det som fanns i hans huvud.

Det är så viktigt att både vi och kunden känner att vi gör projektet tillsammans, att vi sitter i samma båt. Inte att beställaren skickar iväg oss på en resa och frågar 6 månader senare ifall vi kom fram. Systemutveckling skall vara ett partnerskap mellan beställare och leverantör där man känner att man får en ömsesidig förståelse för vilka utmaningar den andre står inför. Det är alltid då det blir bäst resultat.

När allt kommer till kritan måste man ändå fråga sig ifall våra standup meetings, sprintar, product backlog och retrospektiv gör oss mer agila. Hjälper de oss att hantera förändringar i kraven eller förändringar i förutsättningarna för projektet? eller är det bara ”going through the motions”.


Creating the needed capabilities to boost business innovation

Creating the needed capabilities to boost business innovation
Date : 5 juli, 2018

Innovation does not come from itself. Especially not Business Innovation. Many companies devote a smaller or bigger part of their budget to R&D and innovation – but almost always includes developing new products or technologies. In this fast-moving, digital and disruptive world, I believe it’s crucial for our future success to also invest in Business innovation! Discovering unmet customer needs, developing value propositions incorporated into new business models. In my opinion, this investment and strategic work mainly takes place in either start-ups or enterprises. Middle-sized companies tend to be very focused on operations here and now, lacking both the skills, resources and time to devote to more strategic and explorative business development processes.

In his latest blogpost, Alexander Osterwalder nicely illustrates the four key factors needed to be successful in business innovation:

Osterwalder emphasizes that you need to allocate money – preferably 10% of your R&D budget – and manage the money as a Venture Capital firm would; a portfolio of innovation projects. Aligned with the strategy, the directions you want to explore. Some will fail, some will be ok and some might even be your next future cash cow.

Innovation doesn’t happen by itself or by just investing money. It requires time, dedication and empowerment. Leaders should dedicate at least 20% of their time to business innovation, Osterwalder continues. Not interfering with the process, but sharing visions, strategic direction and empowering the team. This is a way to emphasize the importance off innovation in an organization.

As Osterwalder puts it, ”innovation is not done on a Friday afternoon”. People need to be able to dedicate time and resources to truly explore, test and develop new ideas. The right skillset must be available and a combination of seniority and youth can turn ideas to workable business approaches. This process must be supported by the proper processes and incentives – measuring success on other KPIs than the ongoing business.

I’ve conducted numerous workshops with mid-sized companies and in every occasion we have found embryos to new, potentially very interesting business opportunities. Unfortunately, in most cases, there has been no organization, skillset, process or resources available to continue to explore these ideas and turn them into possible future opportunities. How do we get management to realize the importance of investing in business innovation? How do we increase a sense of urgency, that cuts through the feeling of security and ”fat and happy”? How do we help managers and boards to understand that exploring new ideas, even if they might be competing with current business, should be a vital part of the company’s operations as much as other functions? How do YOU address these questions in your company?

Personally, I take comfort in Osterwalder’s blogpost. He meets and discusses these questions with top brand and enterprises all over the world and it’s apparent that not even on those levels, it’s a given that business innovation is a natural part of R&D. Let’s hope that we, by highlighting and discussing the issues more and more can get some actions!


Are you getting ready to start your strategy process for 2019? Let’s try something new!

Date : 26 juni, 2018

It’s that time of the year. First half of 2018 is almost done and we are all getting ready to enter the vacation mode. I hope you’ve had a tremendous year so far! Maybe you’ve exceeded your targets, managed to win that prestigious customer, hired some brilliant people and the future is looking oh so bright! Or, maybe you have experienced a sudden break, lost some precious customers to competitors (maybe even to solutions in adjacent areas), realised that your offering is not hitting home as much as it used to and the people you have on board lack some skills that are increasingly important.

Which ever situation you are in – we are all most likely starting to look at 2019 and the strategy process coming up during the autumn. If you’d like to try a different approach, I recommend looking at the Business Model Canvas and Value Proposition Canvas. The canvas will help you address all the above questions and more in a new manor. You will be collaborating and visualizing what you discuss in a way that increases mutual understanding, provides structure, customer focus and offers new insights. And you will have fun while doing so!

If you’d like to look closer at questions like:

  • how are the trends surrounding my business affecting my business model, offerings, skills and organisation?
  • how can I improve/change my go-to-markets strategy and what new positions can I take?
  • how can better understand my customer and end-user to ensure that I’m helping them solve their jobs better than my competitors are?
  • how can digital solutions improve how we internally collaborate and increase efficiency?
  • how can digital solutions improve my customer experiences, develop new services and new revenue streams?
  • how do we need to change to be better positioned for the future challenges?
  • how do other businesses and industries tackle the same questions and can we learn from them to excel in other industries?

Then why don’t you give me a call at +46 766 447008 or send me an email at kim.hedberg@stratiteq.com and let’s make your strategy process for 2019 one of the best!


Arkitektur handlar om avvägningar

Date : 18 juni, 2018

För ett par år sedan fick jag ett uppdrag av en global läkemedelskoncern att bygga en plattform för deras 2000 varumärkesdrivande webbplatser. Detta var ett stort projekt med mig som arkitekt, ett dussin utvecklare, en testare och 3-4 projektledare. Vi hade strateger och art directors som kom och gick under projektet.

Kundens problem var att de fanns med sina produkter på 200 marknader, varje marknad var självstyrande, så när exempelvis huvudkontoret i Malaysia behövde en ny webbplats för att marknadsföra en produkt eller ett läkemedelsområde i Malaysia, så upphandlade de detta lokalt, fick en lokal IT-partner och driftade det också lokalt. All IT var på så vis distribuerad och enbart vissa stödtjänster erbjöds från corporate.

Detta medför vissa problem

  1. Webbplatserna som producerades höll väldigt låg kvalitet för att man inte hade kunskapen att driva webbprojekt ute i organisationen
  2. IT-miljön blev väldigt spretig och svår att underhålla med olika leverantörer, driftpartners, tekniker
  3. All teknik som utvecklades för Malaysia måste också utvecklas för de andra 199 marknaderna. Enkelt räknat måste varje feature tillämpas 200 gånger
  4. Driftkostnaderna för 200 siter överstiger monumentalt samma kostnad för att drifta 200 siter på en och samma plattform
  5. Det är omöjligt att genomföra globala initiativ, eller ens regionala när tekniken är helt och hållet distribuerad

Mitt uppdrag var att lösa problemen ur en teknisk synvinkel. Med hjälp av EPiServer CMS skulle vi tillhandahålla en plattform som kunde bli ett internt erbjudande till alla marknader utan att inskränka deras självstyre.

En plattform för varumärkeswebbar

När vi tog fram denna lösning hade vi följande ledord.

  • Reuse by content
  • Reuse by features
  • Reuse by technology
  • Reuse by hosting

Läkemedelsbolag har väldigt höga krav på innehållet som produceras och därför måste allt innehåll granskas i en godkännandeprocess innan det publiceras. Detta kan göra innehållsarbete på digitala kanaler trögflytande eftersom det tar tid att få ut nytt innehåll. Därför tog vi fram funktionalitet för ett globalt innehållsbibliotek där varumärkesägare kunde återanvända innehåll som redan gått igenom kvalitetsprocessen.

Istället för att varje site utvecklar sin egen bannerkomponent tog vi fram ett komponentbibliotek med färdiga komponenter som webbplatsägaren kan dra in på sin webbplats för att komponera sidor. Det rör sig om allt från nyhetslistor, navigation, brödsmulor och puffar som kan återanvändas från site till site.

Eftersom plattformen är ett internt erbjudande till olika business units, måste det vara möjligt att använda flera leverantörer och därför skapade vi ett gränssnitt för kreatörer att skapa tema ovanpå webbsiternas funktionalitet. Detta ger synergier när olika leverantörer arbetar med samma tekniker och redaktörerna kan arbeta i samma CMS. Det blir lättare att kommunicera kring digital marknadsföring och hitta en gemensam riktning samt ta gemensamma stratgiska beslut.

Inte minst var driftskostnaderna en drivande faktor för att tillämpa plattformen. Att drifta en plattform med 200 webbsiter kräver färre resurser och lägre kostnad än att hålla 200 driftsmiljöer på lika många marknader.

Avvägningar

Man är naiv om man tror att man kan lösa alla problem med arkitektur. Vad man egentligen gör är att man väger vissa egenskaper som viktigare än andra. Detta är en lärdom som jag tar med mig från projektet.

Vi lyckades maximera återanvändbarheten av olika komponenter, men redaktörsverktyget blev svårare att använda när man tvingas komponera ihop sidor. Effekten blev att det krävdes expertanvändare för att kunna bygga upp webbsidor från grunden, medan vanliga redaktörer fick hålla sig till att göra enstaka tillägg och ändringar.

Om man bygger en plattform där man samlar alla sina webbar då måste man också se till att underhålla den plattformen. Tidigare har man kommit undan med att producera en WordPresswebb och släppa den, men en plattform kräver underhåll och vidareutveckling. Man måste ge support åt sina redaktörer, administratörer, beställare och leverantörer som skall tillhandahålla webbar på plattformen.

Slutligen kommer gemensam drift att sänka den totala driftskostnaden men det kommer också göra alla webbsiter indirekt knutna till varandra. Om en webbsite kräver ny deploy av plattformen kommer detta påverka alla webbar på plattformen. Vi underlättade detta till viss del genom att skapa ett pluginsystem för komponenter och teman, men det hindrar inte en leverantör som gör ett misstag att kunna sänka hela plattformen med alla webbsiter.

Vi väger återanvändbarhet mot komplexitet. Det som tidigare kunde byggas och kastas bort måste nu istället förvaltas. Ett centraliserat system ger lägre driftskostnad men blir mer känsligt för driftstörningar. Detta är de arkitektuella avvägningar vi behövt göra för att lösa kundens ursprungsproblem. Man löser vissa problem och andra problem uppstår till följd av ens lösningar.

Detta hindrade mig inte för att implementera samma koncept för två andra kunder inom livsmedelsbranschen, med nya arkitektuella avvägningar, utmaningar och lärdomar.


Paradigmer styr vår problemlösningsförmåga

Date : 18 maj, 2018

Språket vi använder påverkar sättet vi tänker. De ord och fraser vi använder påverkar vårt förhållningssätt. Detta är något politiker är väldigt bra på, att använda ord för att påverka hur vi uppfattar problem i samhället och påverka debatten.

Detsamma gäller mjukvaruutveckling.

På 50-talet hände något fantastiskt när paradigmen strukturerad programmering uppstod. Tidigare hade man skrivit kod primärt för att maskinen skulle förstå den. Man programmerade maskininstruktioner som datorn skulle exekvera en efter en. Med strukturerad programmering ville man uppnå ett språk som skulle vara för människorna som läser och skriver koden. Man införde IF-THEN-ELSE, WHILE, FOR, subrutiner och kodblock. Detta är element som är fullt integrerade i den kod vi skriver idag, men som ändrade sättet man tänkte på 50-talet.

Denna nya sortens kod som med all fördel skrevs i programspråket Algol, behövde kompileras till maskinkod för att kunna köras av datorn. Givetvis hade också 50-talet sina nej-sägare som menade att en dator aldrig kan skriva lika optimerad maskinkod som en människa. Det är inte många som skulle föra det resonemanget idag.

Den mest populära paradigmen inom programmering är den imperativa objektorienterade programmeringen. Med imperativ menas att program beskriver vad datorn skall göra i den ordning det skall utföras, ungefär som man läser ett recept.

Vispa ägg och socker, blanda med mjöl och bakpulver, in i ugnen 175 grader i 30 minuter. Nu är kakan färdig.

Objektorienterad programmering blev populärt på 90-talet. Den identifierar ett problem med de system som vi bygger, nämligen att vi försöker översätta en komplex domän med noder som på olika sätt relaterar till varandra, till en kod som är helt och hållet imperativ, där en sak händer efter en annan.

I bästa fall kan den endimensionella koden motsvara en dimension av den komplexa domänen.

Med objektorienterad programmering skapar vi klasser och objekt i vår kod som skall efterlikna verklighetens komplexitet för att minska gapet mellan verkligheten och systemets implementation.

Detta nya sätt att tänka förändrade helt och hållet sättet vi bygger system och löser problem med programmering. Man kan säga att det är en revolution som har skett och verktygen har öppnat upp våra hjärnor för en ny sorts problemlösning.

Idag är det objektorienterad programmering som lärs ut på våra universitet och som varje systemutvecklare utgår från när de skall lösa ett problem. Den objektorienterade paradigmen sätter ramarna, men också begränsningar för hur vi löser problem.

Objektorienterad programmering är inte den enda paradigmen. Det finns fler sätt att lösa problem. Ett exempel är deklarativ funktionell programmering. Där utgår man ifrån att vi har data som vi passar in i funktion och får ut annan data, eller förändrad data.

Funktioner kan kombineras, nästlas, köras sekvensiellt eller parallelt, anropa sig själva eller vad som behövs för att uppnå önskat resultat.

Denna paradigm har funnits sedan sent 50-tal men fått ett uppsving de senaste åren som en motreaktion på att objektorienterad programmering helt och hållet tagit över våra programmeringsspråk. Det är inte en dålig modell för att beskriva system på heller. Mycket av det vi gör handlar om att mappa någon form av data till en annan. Det kan vara data i en databas till ett användargränssnitt eller varor i en kundvagn till en order.

Ett exempel på skillnader i paradigmer

Det lättaste sättet att beskriva skillnaden mellan dessa två programmeringsparadigmer skulle vara att göra det i kod.

FizzBuzz är nog den vanligaste programmeringsövningen som används vid anställningsintervjuer av programmerare. Målet är att skriva ett program som skriver ut siffrorna 1..n men där var tredje siffra ersätts med ”fizz”, var femte siffra med ”buzz” och för tal som både ersätts med ”fizz” och ”buzz” exempelvis 15 istället ersätts med ”fizzbuzz”.

En implementation i imperativ objektorienterad C#-kod skulle kunna se ut såhär.

Programmet beskriver imperativt i en följd hur man går till väga för att skapa resultatet. Vi lägger hela resultatet i en resultatlista och returnerar det.

Men bara för att man kan imperativ objektorienterad programmering så skall man inte tro att det är det enda sättet att lösa detta problem på.

En deklarativ funktionell lösning i F# skulle kunna se ut såhär.

Ser ni skillnaden? Detta är inte en imperativ beskrivning av hur FizzBuzz-listan skall skapas. Istället är det deklarerat vad fizzes är, sen vad buzzes är. Följande vad words är och vad numbers är och slutligen att fizzbuzz är en kombination av words och numbers där vi väljer words om det finns, annars numbers.

Hade jag inte kunnat funktionell programmering så hade jag inte vetat att man kan lösa FizzBuzz på detta sätt. Om man kan många paradigmer kan man också välja problemlösningsmetod utifrån problemet man har framför sig. Om man enbart kan objektorienterad programmering, då kommer alla lösningar bli till klasser och objekt.

When all you have is a hammer, every problem will look like a nail.


Bli redo för mikrotjänster

Date : 18 april, 2018

Jag var på plats på Øredev 2013 när Fred George höll sin nästan legendariska dragning Implementing Micro Service Architecture. Jag hade inte hört begreppet förut men skulle snart höra det överallt. Det tog inte långt tid för mikrotjänster att bli IT-världens nya silver bullet.

Vad innebär då mikrotjänster?

I korthet innebär det att man styckar upp ett systems logiska delar i tjänster som tillhandahåller sin funktionalitet genom ett API. Varje tjänst utvecklas, versioneras, lanseras och underhålls som separata applikationer.

Vad är då fördelarna med att skära elefanten i mindre bitar? Det är givetvis flera men några är att

  • En buggfix till produktkatalogen betyder inte att du måste lansera all kod på nytt. Du behöver bara uppdatera produktkatalogens kod.
  • Varje enskild tjänst kommer vara mindre komplex än vad den stora monoliten kommer vara.
  • Att göra varje del i monoliten till en tjänst, tvingar din kod till bättre design och tydligare gränssnitt.

Kort sagt, programmerare älskar det här, men det innebär också en hel del utmaningar.

  • Stark koppling mellan tjänsterna kan innebära att du ändå måste uppdatera samtliga tjänster varje gång du gör en ändring.
  • Det finns en frestelse att dela kod mellan tjänsterna, eller att dela definitioner som ”vad är en order”. Det är en farlig fälla att gå i.
  • Tjänster som anropar andra tjänster blir snabbt en pyramid av tillgänglighetsproblem, där en tjänst kan sänka hela systemet.

Vad kan man göra för att bli redo?

Man måste inse att allt jobb man idag gör för sin monolit måste gå att kvantifiera och automatisera för att man skall kunna hantera 20 – 50 – 100 mikrotjänster. Att sätta upp en ny miljö eller göra en ny deploy måste reduceras till ett par knapptryckningar. Detta går och göra tack vare ett antal tekniska landvinningar det senaste årtiondet

  • DevOps. Se till så att du minimerar avståndet mellan utveckling och produktion, så att kod ”flödar” ut i produktion och användningen återkopplar tillbaka med instrumentation. (Continuous Integration, Continuous Deployment, Provisioning, Monitoring)
  • Testdriven utveckling hjälper till att kvalitetssäkra kod som inte har tid att sitta fast i UAT (user acceptance test) i 3 månader.
  • Dokumentation. Det duger inte att lansera 100 mikrotjänster utan att förklara hur de är tänkt att hänga ihop. Varje tjänst måste tydligt beskriva sitt syfte och sitt gränssnitt, och du måste ha koll på vilka tjänster som används.
  • Versionering. Du måste bli expert på att versionera tjänster, men också att ha koll på bakåtkompabilitet. Skall du lansera en ny tjänst för att du bryter kompabiliteten? hur länge skall du då supportera den gamla tjänsten?
  • Protokoll. Du kommer snabbt upptäcka att komplexiteten flyttar från de enskilda tjänsterna till kommunikationen och kompositionen av tjänster. Det kommer krävas urtydliga sätt att kommunicera med tjänster, men också för tjänster att kommunicera med varandra.

Det bästa tips jag har till dig som funderar på att ge dig i kast med mikrotjänster är att göra det med ett lagom mått av planering. Det går inte att skapa en massa tjänster och tro att de skall självorganisera sig. Då slutar det med att du sitter där med en ny slags monolit vars kodkomponenter kommunicerar över HTTP.


Everybody (?) is talking about Design thinking

Date : 14 april, 2018

Maybe it’s just me, but lately I’ve come across the buzz words Design Thinking, Service Design and an increasing amount of variations of words containing the letters UX (User Experience) or CX (Customer Experience) more and more. And gratefully, the more I study it, the more I realise that design thinking fits very nicely with the tools and methodologies like business model canvas, value proposition canvas and Jobs-to-be-done that I already use on daily basis.

So what is Design thinking?

Design thinking is about understanding the needs of a customer, the behavior, the drivers and the context of where/when/how the customer tries to solve a job, and bringing that knowledge into a solution or product. Design thinking shifts the focus from a business-centric engineering solution (where we invent a product based on a number of assumptions and hope it will work for the customer), to a customer-centric solution based on exploration and understanding of the customer needs. The result being a much higher probability of actually delivering something that the customer will care strongly enough for, to hire/buy and use. Putting more effort in understanding the customer, will make you less dependant on luck for success.

Will focusing on design affect your business results?

In 2013 the Design Management Institute (DMI) decided to start measuring the difference in performance between design-focused companies and S&P over time to study whether investing in design brings value. For the third year in a row, as you can see in the graph below, the DVI-value shows that design-focused companies outperform S&P 500 by as much as 211%, good design drives shareholder value. Read here to learn more about the DVI.

Design Value Index 2005-2015

Whether you’re a CEO, a marketer, or a designer, here are three reasons why your company should invest in design thinking:

  • Improving your UX saves you money
    • A little up-front UX research can save you hundreds of engineering hours and thousands of dollars
    • Decreases the cost of customer support
  • Focusing on UX increases your revenue
    • Increases conversion rates
    • Improves customer retention and loyalty
  • Insisting on great UX drives competitive advantage and affects the bottom line. Just look at Dyson, Uber, Mint, Apple, IBM, and Intuit.

The empowered customer

My background is within marketing and sales, specifically within direct marketing and e-commerce to consumers, where successful business results always required delivering something the customer wanted/needed to be able to both get conversion and retention. The more I now work with B2B-companies, I realise that thinking about and focusing on the customer – or actually the end-user – is not done nearly enough. Bringing design thinking, and applying the methodologies surrounding it, to the B2B-world, could potentially have a huge impact on both new products and solutions as well as business models. But how do we get management to understand the value and need of it?

The empowered customer is slowly creating the shift within B2B as well, and with the growth of B2B e-commerce there will be an increasing understanding of other relevant KPI’s to measure – be it conversion, retention, shopping cart abandonment and so forth. It’s an easy area to apply design thinking and the results of optimising accordingly are visual and quick. This is one way of increasing the knowledge and importance of design and UX.

McKinsey is launching concept design sprints

Another sign of the increasing focus on design thinking, is when McKinsey and the likes are bringing the concept of design sprints to the market. McKinsey recently published an article on how concept design sprints could increase the customer experience innovation. It’s a concept based on how companies within 5 days can go through the steps of identifying a problem, coming up with a solution, prototyping and eventually, on the 5th day, testing it with real customers. An agile way of quickly testing out an idea and solution, learning from real customer feedback to be able to (with or without pivoting) launching a solution more likely to succeed. McKinsey is basing its concept on Google Venture’s design sprint concept, which in my opinion is brilliantly described in the Sprint book by Jake Knapp. McKinsey is thus not the first to bring it to the market, but the significance is that both the knowledge and the importance of design thinking is spread to much larger community, bringing credibility to the buzz word.

I look forward to participating in future design sprints and love the fact that it will be easier and easier to get our customers to understand and try out being more customer/end-user focused!


Are you solving a job your end-user cares strongly about?

Date : 9 april, 2018

If you are a traditional B2B-company, chances are you are getting most of your input for product development from your customers. And with customers, I mean distributors, partners, retailers and others to whom you sell your products, and who then distribute and sell them to your end-users. So how do you know if your products are solving a job the end-user cares strongly about? And are you positioning and explaining the value you deliver to them in a way that is relevant to them?

An example

A company I recently worked with, GCE Group, is developing a new product, which with the help of IoT, will bring them closer to the end-user than they have been so far. They might not want to sell to them, but they definitely want to communicate with them and turn them into advocates for their product. The end-users are patients with respiratory problems due to different diseases. The buyers, i.e. customers, however are hospitals. And they have completely different jobs, pains and gains.

Jobs-to-be-done perspective

The Jobs-to-be-done concept is based on the work of among others Tony Ulwick, and was made popular by the known Harvard professor Clayton Christensen with his research around what job a milkshake is hired to do. In short, the theory explains that a customer  will hire a product or service to help them get a job done. The product or service hired is merely a tool or technology to help them solve a particular job, and is strongly influenced by the context of where and when the job is being performed. In the milkshake experiment mentioned above, it turned out that commuters were buying milkshakes when driving to work, mainly to have something to do. The milkshake fit well in one hand (the other being on the steering wheel) and was filling enough to keep them from getting hungry before lunch. Once the fast-food restaurant, who ordered the research, had understood the job the milkshake was hired to do, product development could be focused on making the milkshake thicker, chunkier and with a thinner straw. Thereby solving the job even better than the previous solution.

Back to GCE Group

As many other manufacturing B2B-companies, GCE was really proud of their new product with tons of nice features. The communication was based around these features, without actually taking into consideration the job that the recipient of the communication was actually trying to solve. Using the Value Proposition Canvas from Alexander Osterwalder’s toolbox, we looked closer at the jobs, pains and gains of the different target groups; the hospital who is the buyer (and from GCE perspective the customer), the patient who is the end-user and the clinician who is the prescriber.

The hospital’s main job is to provide care and to lower operational cost – so GCE needs to describe how their product can help lower operational cost while at the same time offering good treatment and care. Conveying this message by describing product features is maybe not the optimal way, but rather requires messaging explaining e.g. the total cost of ownership of the product compared to current solutions.

The patient is really just trying to live a normal life for as long as possible. Meaning being able to socialize with friends, maybe being able to continue working or taking small walks. Things we take for granted when we are not suffering from a disease. Hence the communication has to highlight which features of the product that helps the patient solve this job. And finally, looking at the clinician, he/she is focusing on delivering a treatment that will help their patient, but at the same time has to consider the number of patients he/she is able to see during for example an hour. As the IoT in the product makes it possible to give treatment remotely, the value that this feature delivers might be the most important to convey to the clinician.

Concluding, the same product can have several different value propositions depending on the target group and what job that specific person is trying to solve. By focusing on understanding your target group’s actual jobs, you can improve your sales just by being able to communicate the actual value you are already delivering to them. My experience so far has been that few B2B companies actually speak to end-users to truly understand what difference you can make for them. Are you among them?

Do you want to learn more about the work we have done with GCE Group, download our customer case from our web. Do you wish to have the customer case in English, contact me at kim.hedberg@stratiteq.com.

 

 


Bäst före datum för webb

Date : 19 mars, 2018

När jag började min konsultkarrär inom webb var Flash det fräsigaste i designkretsar. Inte bara att man kunde göra ”vad som helst” men för att det bryggade gapet mellan designers och utvecklare.

Jag var stursk och tyckte att ”Flash kommer inte hålla mer än 3 år”. Problemen var uppenbara, en proprietär teknik i en webb vars framfart är byggd på öppna standarder. Jag fick rätt och alla Flash-utvecklare brandade om sig till gränssnittsutvecklare och började jobba med jQuery.

Idag är det förhoppningsvis ingen som behöver installera Adobe Flash Player plugin på sin dator.

Utvecklingen på webben går rasande fort. Det finns knappt något spår kvar av Flash som tidigare fanns på var och varannan sida. Utdöende tekniker dödar webbsidor. När tekniken sidan är byggd på börjar bli gammal, då måste sidan byggas om och bytas ut.

jQuery som blev javascript-ramverket efter Flash är nu en bespottad teknik. Istället skall allt byggas i React, men vi skall inte låta oss luras. React är inte det sista gränssnittsramverket. Det kommer också vara åldrigt om 3 år.

Det är inte bara tekniken som har ett bäst före datum. När man tittar på gamla webbplatser ser man direkt att de har några år på nacken. Det går trender i webbdesign på samma sätt som det går trender i all design.

För ett par år sedan när CSS3 fick stöd i allt fler webbläsare blev det också mycket lättare att skapa animationer. Då uppstod parallax-effekten och spred sig som en löpeld. Alla sidor skulle ha en bakgrund som rörde sig parallellt när man skrollade.

Detta försvann lika fort som det uppstod när effekten blev main stream. Den ersattes då av animeringar som byggde upp sidan allt eftersom man scrollade. Knappar flög in och bilder poppade upp när man scrollade neråt. Detta fick också en kortvarig livstid då det var ganska dyrt att bygga och tillförde väldigt lite.

Kreativt parallaxande som tar fokus från innehållet och lägger den på designen.

Kommer ni ihåg menyerna som kunde ta över hela sidan och presentera jättemycket information? Det framgick ganska snabbt att det var en dålig idé eftersom det blev svårare att hitta saker.

Microsoft gillade sin take-over menu. Hittar du vad du söker?

Hamburgermenyn har kommit i dålig dager. Har ni märkt att allt färre responsiva gränssnitt designas med en hamburgermeny? Istället jobbar man med informationshiarkin för att skapa en enklare navigering. Det kan vara svårt i vissa lägen.

Att McDonalds skulle ha en hamburgermeny var givet.

Förra året, 2017, var året då huvudbannern fick ett större fokus och kunde ta över hela startsidan. Jag tycker att det påminner ganska mycket om hur Flash användes 2007. Vi får se hur länge det håller in i 2018.


Utvecklarskrivna tester ersätter inte behovet av testning

Date : 19 januari, 2018

Jag skriver mycket kod. Det är en svår övning och inte som många tror, bara att skriva ner kraven så att en maskin skall förstå dem. Det är lätt att det blir fel, särskilt när man utgår från ett blankt ark och skall skriva kod som är snabb, effektiv, lätt att läsa och underhålla. Sen skall den visst fungera också. Koden skall inte bara uppfylla sin uppgift, den skall ha ett gränssnitt man vill använda, den skall kunna indexeras av sökmotorer läggas ut i molnet och funka där.

Det vet vi alla hur svårt det är att bara skriva ett mail som får fram budskapet hos läsaren. Det är svårt att skriva kod. Därför har jag en metod.

När jag får en specifikation börjar jag med att skriva ner kraven som körbara program som verifierar att mitt system uppfyller kraven. Sen implementerar jag systemet så att det ett efter ett annat uppfyller de tester av mina krav som jag skrev först. Detta kallas testdriven utveckling och är en metod för att skriva kod på ett sätt som är säkert, stabilt och genomtänkt.

Testdriven utvecklingsprocess

En bieffekt är att vi får en testsvit som låter oss verifiera kraven mot systemet gång på gång. Ändringar som bryter systemet kommer upptäckas tidigare.

Jag får ofta höra att testdriven utvecklingsmetod gör att vi inte behöver testare i projektet. Detta kommer från personer som inte förstår att testdriven utveckling är en metod för att skriva kod och inte en testmetod. Felet ligger givetvis i namnet som antyder att det hela har med testning att göra.

Testaren bidrar med att hitta kraven som avgör ifall funktionen är klar eller inte. Uppfyller den utvecklade funktionen användarnas behov på ett tillfredställande sätt, eller måste vi ändra och göra tillägg för att nå i mål? Kortfattat saknas en viktig pusselbit i diagrammet ovan, nämligen frågan, ”är funktionen färdig”?

Testdriven utvecklingsprocess med testare.

Sanningen är att testdriven utveckling faktiskt leder till ett lägre behov av testning i projektet, men inte för att utvecklare har tagit över testarens uppgifter, utan att testdriven utveckling är en metod som leder till färre buggar. Detta frigör tid för testaren som kan lägga mindre tid åt att faktakolla utvecklaren, och mer tid åt att experimentera och utmana ifall systemet verkligen löser användarens problem. Det är trots allt där våra testare kan bidra mest.


Facilitate PIM enrichment with in context editing

Date : 11 januari, 2018

InRiver PIM has many useful features for further improvement of the user experience and/or to streamline daily work tasks. A recent addition is In context editing, allowing you to set up editable views of your product information in its context. I really like this way to set up for exampel a view that looks like the product page on your website where you can work with enrichment of fields from product as well as item entities in one and the same view.

A customized input table for certain kind of data, an adjusted view of technical data that make more sense to the editors or a view with campaign content are other ways in context editing could facilitate enrichment work.

The function could also be used to present information from external systems or be integrated with web services to create useful tools, as an example used to create a viewer of media types that are not supported out of the box in PIM.

Working as PIM responsible at a company within the marine industry my main challenge was the implementation of the new work process. New products were only added to our product assortment a few times a year. This made it a bit hard for my colleagues, who were not working in the PIM system on a daily basis, to remember how to work with enrichment of data from one time to the next. Had the in context editing function been available back then, it would definitely have been a solution to the problem, where the editors could make their part of the work in a view that were more familiar to them.

Edit in context was launched with Product Marketing Cloud (iPMC), but can also be used in InRiver 6.3 with servicepack 3 installed.


The common denominator

Date : 22 december, 2017

As I look back upon 2017, the trend is clear. During the year I’ve conducted around 20 workshops (about 50 days) where I’ve used the Business Model Generation toolbox. The workshops have been conducted with more than 12 different companies, mostly midsized B2B-companies, but in very different industries – from chemistry to insurance. Despite their differing industries, I conclude that the similarities are greater than the differences. Most of them are struggling with understanding digital transformation – what does it mean for them as companies – and how do they move beyond focusing on digitalization as such, to understanding what they actually want to achieve – with their business models, value propositions and customer experiences? Viewing digital solutions as a means to an end – rather than the sole purpose.

Fat and happy or the knife to the throat – who has the greatest challenge?

Some of the companies are not fat and happy. They are actually already struggling with the consequences of digital disrupters changing their industries. They go to market with products that are becoming more and more commoditized, adding little extra value to earn the premium price they want to charge. Some of them are seeing thinner and thinner margins due to the price transparency of an ever more present e-commerce within B2B. Others are better off. They have a thriving business, they might operate in a conservative industry where neither customer nor competitor are digitally mature. Who is worse off? Which challenges are greater? Finding a solution when forced to it or realizing that you need to prepare for the future and find some sense of urgency when all is going well?

I believe the challenges are equally great – only timing matters. When forced we can be very creative, we are willing to take risks and the sense of urgency is a gathering force for all to focus on finding new solutions. There is no possibility to stand in the corner and mutter that ”this does not concern me”. When you are in the latter situation, I tend to congratulate my customers. They are wise enough to realize that their current business model will not last forever and at the same time they have the time to think things through, test and evaluate before implementing new solutions and business models. Their challenge is rather to gather the energy, focus and create the necessary insight and willingness to change – although not being forced to it for the time being.

Your customer is not always your end-user – to whom do you create value?

The most common denominator of all however, is the lack of end-user insights. Most of our customers go to market via partners, retailers, distributors or other channels. Very few actually sell directly to the end-user. It’s true, they do know a lot about their customer. But not about the end-user – the true customer. Introducing the concept of Jobs-To-Be-Done and the Value Proposition canvas is the greatest value I can bring to our customers right now. The realization and understanding of the jobs their end-users are trying to solve, the pains and thresholds connected with it and the gains – what the end-user really wants to achieve when successful – is the Holy Grail to being innovative and identifying new value propositions. Be it digital services connected to physical products, new features to underserved end-users opening up new market segments or simply improving customer experience by sharing content, knowledge and information already available within our organizations but not to our customers.

Stay tuned for a new blog post where I will describe the jobs-to-be-done concept and value proposition in more detail! Meanwhile have a look at this short introduction describing the Value Proposition Canvas.

 

I now look forward to 2018. We already have 5 workshops planned, most of them with new customers in new industries. It will be interesting to get the opportunity to get to know them better and I’m sure new ideas and solutions will arise!