Entreprenørskap handler om å bygge systemer, ikke samle ideer

Kort fortalt: Når man arbeider med eiendom, programvare, innhold og egne merkevarer samtidig, er det lett å forveksle aktivitet med fremdrift. For meg handler strategi om å velge hva som skal henge sammen, hva som skal forbli selvstendig og hva som faktisk skal fullføres.

Hvordan kan ulike prosjekter styrke hverandre?

Eiendom gir innsikt i kundespørsmål og arbeidsprosesser. Programvare kan gjøre oppfølgingen mer systematisk. Innhold kan gjøre kunnskapen tilgjengelig før første samtale. Hvert prosjekt har sin egen kunde og sitt eget løfte, men læring kan deles.

Det er forskjell på en felles arbeidsplattform og en utydelig felles merkevare. Kundene skal alltid forstå hvem de handler med, hva de får og hvor ansvaret ligger.

Hva er forskjellen mellom strategi og en full oppgaveliste?

En oppgaveliste beskriver hva man kan gjøre. En strategi viser hvorfor noen oppgaver må komme før andre, og hvilke muligheter som derfor må vente.

Jeg forsøker å bruke en enkel test: Forbedrer dette kundeopplevelsen, kvaliteten på leveransen eller muligheten til å skape en bærekraftig virksomhet? Hvis svaret er uklart, er det ikke nødvendigvis riktig neste steg.

Hvordan bør en ny idé testes?

Beskriv først en konkret bruker, et konkret problem og en realistisk betalingsvilje. Lag en liten løsning som viser om problemet faktisk blir enklere å håndtere.

Test med mennesker som kan si nei. Det er mer verdifullt å lære hvorfor de ikke ville betalt enn å få høflige tilbakemeldinger på en imponerende demo.

Hvorfor er tydelig kommunikasjon viktig?

Et godt system kan fortsatt mislykkes hvis det forklares med interne tekniske begreper. Kunden ønsker å forstå hvilken forskjell løsningen gjør i hverdagen.

Derfor bør kommunikasjonen begynne med behovet og resultatet, før den beskriver teknologien og metoden.

Når flere merkevarer deler teknologi

Zen Eco Homes, Pinoso Ecolife, Doña Anna og programvareprosjektene løser forskjellige behov. Det er ikke en fordel å blande kundeopplevelsene. Derimot kan en felles teknisk grunnmur redusere dobbeltarbeid innen oppgaver som tilgangsstyring, innholdsproduksjon, dokumentasjon og oppfølging.

Skillet er viktig: Del den infrastrukturen som bør være felles, men la hvert prosjekt ha en tydelig ansvarlig, målgruppe og verdi for kunden.

Hvordan velger jeg mellom å bygge selv og kjøpe en tjeneste?

Først spør jeg om funksjonen skaper et særpreg for virksomheten. En standardoppgave som betalingsbehandling løses ofte best med etablert programvare. En arbeidsflyt som kombinerer lokal bransjekunnskap, dokumenter og kundeoppfølging kan i større grad forsvare egen utvikling.

Det er likevel en feil å bygge alt internt. Driftskostnader, sikkerhet, vedlikehold, kompetanse og avhengigheter må med i vurderingen.

Hva må være på plass før en SaaS-løsning skaleres?

En kunde må forstå gevinsten uten å kjenne teknologien. Løsningen må tåle ulike brukere, tilgangsnivåer og forventninger til databehandling. Support og onboarding er en del av produktet, ikke tillegg som kan utsettes på ubestemt tid.

Betalingsvilje bør testes tidlig. Noen få kunder som faktisk bruker og betaler for en avgrenset løsning kan gi bedre læring enn et omfattende produkt som ennå ikke har funnet sin målgruppe.

Hvorfor dokumentere beslutninger underveis?

Når et prosjekt vokser, blir historien bak tekniske og kommersielle valg lett borte. Jeg foretrekker å dokumentere beslutning, begrunnelse, alternativer og når den skal vurderes på nytt.

Slik blir det lettere å samarbeide, gi ansvar til andre og forbedre løsningen uten å måtte rekonstruere hva som skjedde flere måneder tidligere.

Les videre

Disse sidene utdyper arbeidet og gjør det enklere å finne riktig neste steg.

Om forfatteren

Freddy Bremseth er entreprenør, eiendomsrådgiver og forfatter bosatt i Benidorm-området. Han arbeider med eiendom på Costa Blanca, digitale systemer og merkevareutvikling, blant annet RealtyFlow, Nexus og Doña Anna.

Mer om Freddy Bremseth →