Sari la conținut
SEM ROI
Vorbește cu noi
Studiu de caz · Product management la client

Doi parteneri de dezvoltare, un singur product owner

Un grup de resorturi și-a reconstruit site-ul și aplicația pentru oaspeți cu doi parteneri. Noi asigurăm rolul de product owner de partea grupului, așa că brieful, deciziile și scope-ul rămân într-un singur loc.

Client
Grup de resorturi cu mai multe branduri (nume confidențial)
Sector
Ospitalitate · portofoliu multi-brand
Piață
Mediterana · oaspeți internaționali
Perioadă
2026 – în curs
Rolul nostru
Management de produs și product ownership de partea clientului pentru web, aplicație și active digitale, în toate brandurile
  • Management de produs
  • Product ownership
  • Livrare multi-vendor
  • Discovery
  • Arhitectură tehnică
  • Operațiuni cu AI
branduri, un responsabil pentru web, app și active digitale
4
direcții: site, aplicație pentru oaspeți, sistem operațional
3
parteneri de livrare, briefați prin același strat de produs
2
registru de decizii; fiecare întrebare are un responsabil
1

Aria colaborării în octombrie 2026. Indicatorii de livrare vor fi adăugați după lansare.

Provocarea

O reconstrucție, mulți parteneri și departamente

Site, aplicație pentru oaspeți și sisteme back-end, construite de doi parteneri pentru departamente cu propriile priorități. Cineva de partea clientului trebuia să le transforme într-un singur produs.

Ce trebuia să livrăm
  • Cerințele tuturor departamentelor, într-o singură listă de prioritățiRealizat
  • Direcția de platformă, stabilită înainte de ofertarea dezvoltăriiRealizat
  • Ambii parteneri lucrează pe aceeași versiune de scopeÎn curs
  • Grupul să-și poată gestiona singur conținutul după lansareÎn desfășurare

  • Designul și dezvoltarea, la companii diferite

    Aplicația este proiectată de un partener și construită de altul. Fiecare predare e un loc unde o funcționalitate poate cădea între contracte și rămâne neofertată.

  • Un brief scris înainte de constrângeri

    Cerințele au fost scrise înainte ca limitele platformelor să fie clare, așa că unele puncte au trebuit rescrise ca un partener să le poată oferta.

  • Fiecare departament avea altă prioritate

    Fiecare departament avea argumente solide, iar nu toate mergeau în aceeași direcție.

  • Platforme care stabilesc limitele

    Motorul de rezervări și celelalte sisteme terțe limitează fiecare ce le poate promite oaspeților noul front-end.

Ce am făcut

Șase direcții de lucru, gestionate ca o singură practică de produs

Am revizuit brieful înainte ca partenerii să-l oferteze, am construit o singură bază de dovezi și am dus fiecare constrângere la oamenii care puteau decide asupra ei.

Secvența programului2026 – în curs

Doar secvența. Datele calendaristice nu apar în acest studiu de caz.

  1. Revizuirea briefuluiÎnainte de contract

    Cerințe verificate înainte ca cineva să le oferteze

    • O revizuire rând cu rând a cerințelor pentru aplicație și web: goluri, ambiguități și puncte care cereau întâi o decizie.
    • Acoperirea verificată pentru ce are nevoie o aplicație nativă: confidențialitate și consimțământ, localizare, notificări, migrarea datelor.
    • Punctele pe care niciun partener nu le putea oferta în forma lor au fost rescrise sau împărțite înainte să fie preluate în contract.

    RezultatÎntrebările de scope au primit răspuns înainte de semnare, nu prin cereri de modificare.

  2. DiscoveryÎn curs

    O singură bază de dovezi pentru ambii parteneri

    • Interviuri cu fiecare departament și un chestionar structurat pentru echipele de management ale hotelurilor din toate brandurile.
    • Un plan de cercetare cu utilizatorii, construit în jurul felului în care oaspeții decid și rezervă, nu al plângerilor despre interfața actuală.
    • Concluziile etichetate după nivelul de încredere, astfel încât un semnal timpuriu nu e prezentat ca rezultat definitiv.

    RezultatAmbii parteneri proiectează pornind de la aceleași concluzii.

  3. Guvernanța designului

    Feedback din multe surse, un singur registru

    • Feedbackul de design de la departamente, echipele hotelurilor și conducere, consolidat într-un singur registru.
    • Conflictele și dependențele, scoase la suprafață, nu mediate.
    • Fiecare punct clasificat ca Design, Lucru suplimentar sau Decizie în așteptare, cu punctele critice ancorate în formularea originală a persoanei care le-a ridicat.

    RezultatFiecare cerere de modificare poate fi urmărită până la sursă.

  4. Decizii de arhitectură

    Constrângeri duse la oamenii care le pot schimba

    • Limitele platformelor terțe, documentate înainte să devină probleme de design.
    • O sesiune comună cu echipa IT a grupului și ambii parteneri: direcția de platformă stabilită, cu argumentele consemnate.
    • Întrebările deschise, înregistrate fiecare cu un responsabil și forul care decide.

    RezultatDirecția de platformă, stabilită înainte de estimarea dezvoltării.

  5. Alinierea partenerilorÎn curs

    Doi parteneri, o singură versiune de scope

    • Fiecare decizie consemnată o singură dată, cu responsabil și argumente, și transmisă partenerilor ca scope agreat.
    • O specificație de predare de la design la dezvoltare, asumată în comun de ambii parteneri, care acoperă ce trece între web și aplicație.
    • Cererile din afara scope-ului agreat, înregistrate și amânate pentru o etapă ulterioară, în loc să fie absorbite.

    RezultatPartenerii lucrează pe același scope, deja stabilit.

  6. Modelul operaționalÎn desfășurare

    Grupul își deține infrastructura; partenerii lucrează în ea

    • Hosting, medii și repository-uri de cod configurate în conturile proprii ale grupului, cu acces pentru parteneri.
    • Ciclul de viață al platformei și al CMS-ului inclus în roadmap, nu lăsat la voia întâmplării.
    • Conținutul de după lansare și actualizările de rutină, planificate intern, cu asistență AI în CMS.

    RezultatMai puțină dependență de un singur partener după lansare.

Secvența programului2026 – în curs
01Revizuirea briefuluiÎnainte de contract

Cerințe verificate înainte ca cineva să le oferteze

  • O revizuire rând cu rând a cerințelor pentru aplicație și web: goluri, ambiguități și puncte care cereau întâi o decizie.
  • Acoperirea verificată pentru ce are nevoie o aplicație nativă: confidențialitate și consimțământ, localizare, notificări, migrarea datelor.
  • Punctele pe care niciun partener nu le putea oferta în forma lor au fost rescrise sau împărțite înainte să fie preluate în contract.

RezultatÎntrebările de scope au primit răspuns înainte de semnare, nu prin cereri de modificare.

02DiscoveryÎn curs

O singură bază de dovezi pentru ambii parteneri

  • Interviuri cu fiecare departament și un chestionar structurat pentru echipele de management ale hotelurilor din toate brandurile.
  • Un plan de cercetare cu utilizatorii, construit în jurul felului în care oaspeții decid și rezervă, nu al plângerilor despre interfața actuală.
  • Concluziile etichetate după nivelul de încredere, astfel încât un semnal timpuriu nu e prezentat ca rezultat definitiv.

RezultatAmbii parteneri proiectează pornind de la aceleași concluzii.

03Guvernanța designului

Feedback din multe surse, un singur registru

  • Feedbackul de design de la departamente, echipele hotelurilor și conducere, consolidat într-un singur registru.
  • Conflictele și dependențele, scoase la suprafață, nu mediate.
  • Fiecare punct clasificat ca Design, Lucru suplimentar sau Decizie în așteptare, cu punctele critice ancorate în formularea originală a persoanei care le-a ridicat.

RezultatFiecare cerere de modificare poate fi urmărită până la sursă.

04Decizii de arhitectură

Constrângeri duse la oamenii care le pot schimba

  • Limitele platformelor terțe, documentate înainte să devină probleme de design.
  • O sesiune comună cu echipa IT a grupului și ambii parteneri: direcția de platformă stabilită, cu argumentele consemnate.
  • Întrebările deschise, înregistrate fiecare cu un responsabil și forul care decide.

RezultatDirecția de platformă, stabilită înainte de estimarea dezvoltării.

05Alinierea partenerilorÎn curs

Doi parteneri, o singură versiune de scope

  • Fiecare decizie consemnată o singură dată, cu responsabil și argumente, și transmisă partenerilor ca scope agreat.
  • O specificație de predare de la design la dezvoltare, asumată în comun de ambii parteneri, care acoperă ce trece între web și aplicație.
  • Cererile din afara scope-ului agreat, înregistrate și amânate pentru o etapă ulterioară, în loc să fie absorbite.

RezultatPartenerii lucrează pe același scope, deja stabilit.

06Modelul operaționalÎn desfășurare

Grupul își deține infrastructura; partenerii lucrează în ea

  • Hosting, medii și repository-uri de cod configurate în conturile proprii ale grupului, cu acces pentru parteneri.
  • Ciclul de viață al platformei și al CMS-ului inclus în roadmap, nu lăsat la voia întâmplării.
  • Conținutul de după lansare și actualizările de rutină, planificate intern, cu asistență AI în CMS.

RezultatMai puțină dependență de un singur partener după lansare.

Cum lucrăm

Unde ajunge fiecare cerere

Cererile vin de la departamente, echipele hotelurilor, conducere și ambii parteneri. Fiecare trece prin același strat de produs înainte să ajungă la un partener.

Intrări
  • Departamente
  • Echipele hotelurilor
  • Conducere
  • Parteneri
  • Cercetare cu oaspeți
Strat de produs · la client
  1. Consolidare
  2. Verificare față de sursă
  3. Clasificare
Ieșiri
  • Designpartenerul de design
  • Lucru suplimentarofertat ca modificare sau amânat pentru o etapă ulterioară
  • Decizie în așteptareforul potrivit (IT, revenue, conducere), cu un responsabil
  • Limită de platformăregistrul deciziilor de arhitectură

Un singur traseu pentru fiecare cerere. Nimic nu ajunge la un partener fără o clasificare și o sursă.

În tot portofoliul

Un singur product owner pentru patru branduri

Patru branduri, oaspeți diferiți, un singur portofoliu. Deciziile se iau o singură dată acolo unde brandurile au lucruri în comun și rămân separate acolo unde diferă.

  • Brandul A
  • Brandul B
  • Brandul C
  • Brandul D
Hosting · securitate · analytics · CMS

  1. Decis o dată, aplicat tuturor brandurilor

    Alegerile de hosting, securitate, analytics și CMS se fac la nivel de grup, ca fiecare brand să nu repete aceeași evaluare.

  2. Fiecare brand își păstrează poziționarea

    Componentele și standardele comune stau dedesubt; tonul, conținutul și experiența oaspeților rămân ale brandului.

  3. Lecții duse mai departe

    Ce învață proiectul unui brand despre parteneri, platforme și conținut intră în următorul brief.

  4. Suport dimensionat pe istoricul real

    Nevoile de mentenanță și suport sunt estimate din ce au necesitat efectiv site-urile existente, nu dintr-un abonament generic.

Înainte și după

Cum funcționează programul acum

DomeniuÎnainteAcum
FeedbackFiecare departament vorbea direct cu parteneriiUn singur registru, clasificat și cu surse
ConstrângeriDescoperite în timpul designuluiDuse mai întâi la cei care decid
DeciziiLuate în ședințe, ținute minte diferitConsemnate cu responsabil și argumente
Modificări de scopeTratate de la caz la cazÎnregistrate, ofertate sau amânate
Conținut după lansareUn tichet către partenerIntern, cu asistență AIplanificat

  • Feedback

    Acum: Un singur registru, clasificat și cu surse

    Înainte: Fiecare departament vorbea direct cu partenerii

  • Constrângeri

    Acum: Duse mai întâi la cei care decid

    Înainte: Descoperite în timpul designului

  • Decizii

    Acum: Consemnate cu responsabil și argumente

    Înainte: Luate în ședințe, ținute minte diferit

  • Modificări de scope

    Acum: Înregistrate, ofertate sau amânate

    Înainte: Tratate de la caz la caz

  • Conținut după lansare

    Acum: Intern, cu asistență AIplanificat

    Înainte: Un tichet către partener

Ce am învățat

  1. Riscul stă între parteneri

    Niciunul dintre parteneri nu era problema. Problema erau funcționalitățile pe care nu le deținea nimeni. Maparea timpurie a fiecărei predări a arătat unde scope-ul ar fi rămas altfel neofertat.

  2. Du constrângerea la oamenii care o pot schimba

    Când o funcționalitate dorită de oaspeți depinde de ce permite o platformă terță, răspunsul nu e un design mai ingenios. E o decizie pentru cei care dețin platforma și condițiile ei comerciale, așa că acolo o ducem.

  3. AI-ul grăbește consolidarea; sursele o țin onestă

    Rezumatele deviază. O notă care spunea un lucru poate fi parafrazată într-o afirmație mai puternică. Folosim AI pentru consolidare la scară și ancorăm fiecare punct critic în cuvintele persoanei implicate.

Gestionezi un program cu mai mulți parteneri?

Spune-ne ce construiești și cine îl construiește. Îți arătăm unde sunt probabil golurile și cum am gestiona partea de produs.

Discută despre programToate studiile de caz
Noua pagină principală Horeca Papatya pe Shopify
Următorul studiu de caz · HoReCa
Horeca Papatya: jumătate din venitul online, din Google