🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🤝 धडा 02 — Platform as a product: शिक्षिका या कार्यालयाच्या ग्राहक आहेत

📍 तुम्ही इथे आहात: 12 पैकी धडा 02 · मागे: lesson-01-why-platforms · पुढे: lesson-03-golden-paths

📦 या ब्रँचमध्ये काय आहे

धडा 01, आणि platform वापरला जाईल की दुर्लक्षित होईल हे ठरवणारी विचारसरणी: त्याला एक product माना. Teams या users आहेत. तुम्ही त्यांची मुलाखत घेता, त्यांचे त्रास क्रमाने लावता, सर्वात मोठ्या त्रासापासून खाली एक roadmap बनवता, आणि adoption मोजता — platform स्वतः निवडणाऱ्या teams — सक्ती करून तो लादण्याऐवजी. idp/office.py मधले rank_pains() आणि adoption(), आणि idp/demo.py मधले product().

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

दीपिका सुविधा कार्यालय चालवते. या महिन्यात तिच्याकडे एकाच नव्या संचाचे बजेट आहे.

तिला सगळ्यात जास्त मजेदार वाटणारी गोष्ट ती बनवू शकली असती: एक चकचकीत smart-board संच. 🖥️ त्याऐवजी ती एक वही घेऊन शाळेत फिरते आणि प्रत्येक विभागाला विचारते: "तुमचा वेळ कशात वाया जातो? आठवड्याला किती तास?"

विज्ञान विभाग म्हणतो: "lab database ची वाट पाहण्यात — आठवड्याला 6 तास."
गणित विभाग म्हणतो: "database ची वाट पाहण्यात — 4 तास. वेळापत्रकाचा screen कोणाचा हे शोधण्यात — 1 तास."
क्रीडा विभाग म्हणतो: "database ची वाट पाहण्यात — 5 तास."

ती सगळे बेरीज करते. database ची वाट पाहण्यात संपूर्ण शाळेचे आठवड्याला 15 तास जातात. तोच पहिला संच. smart board नाही.

मग ती कोणालाही तो वापरायचा आदेश देत नाही. ती तो इतका चांगला बनवते की विभागांना तो हवासा वाटतो. किती जण तो निवडतात ते ती मोजते: पहिल्या महिन्यात 5 पैकी 1, तिसऱ्या महिन्यात 5 पैकी 3, सहाव्या महिन्यात 5 पैकी 4. जेव्हा कला विभाग "नको, धन्यवाद" म्हणतो, तेव्हा ती का ते विचारते — ते उत्तरच तिचे पुढचे काम आहे.

🗺️ आकृती

flowchart LR
    i["🗣️ interviews<br/>5 departments"] --> r["📊 rank by hours lost<br/>database 15 h/week<br/>CI YAML 7 · owner lookup 5"]
    r --> m["🗺️ roadmap<br/>biggest pain first"]
    m --> b["🧰 build the kit"]
    b --> a["📈 adoption<br/>20% → 60% → 80%"]
    a -->|"teams that leave: ask why"| i

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l02

❓ काय

Platform as a product — platform team एखाद्या product team सारखी काम करते: तिचे users असतात, ती user research करते, सार्वजनिक roadmap ठेवते, documentation आणि release notes लिहिते, आणि users चे भले झाले का ते मोजते. CNCF Platforms White Paper आणि Team Topologies दोन्ही platforms चे वर्णन असेच करतात.
Users (अंतर्गत ग्राहक) — platform वर बांधकाम करणारे developers आणि teams. त्या सहसा त्याला वळसा घालू शकतात (स्वतःचे Terraform लिहून, cloud console वापरून), म्हणून platform ला आपली जागा मिळवावी लागते.
User interviews — users शी त्यांच्या कामाबद्दल आणि त्रासांबद्दल बोलणे, "तुम्हाला feature X आवडेल का?" असे विचारणे नाही. चांगले प्रश्न भूतकाळाबद्दल असतात: "मागच्या वेळी तुम्हाला database लागला तेव्हा काय झाले?"
Roadmap — कार्यालय काय बनवणार याची क्रमवार यादी. मूल्यानुसार क्रम लावलेली (इथे: आठवड्याला वाया जाणारे तास, मग किती teams ना तो जाणवतो), बनवायला काय मजेदार आहे त्यानुसार नाही.
Adoption — platform वापरणाऱ्या teams चा वाटा. वापर स्वेच्छेने असेल तर adoption हा प्रामाणिक feedback असतो. सक्ती ("Q3 पर्यंत सगळ्यांनी तो वापरलाच पाहिजे") मुळे आकडा वाढतो, पण product चांगले आहे की नाही हे कळत नाही.
Thinnest viable platform (TVP) — Team Topologies ची कल्पना: मदत करणाऱ्या सर्वात लहान गोष्टीपासून सुरुवात करा — चांगल्या defaults चे एक wiki पान सुद्धा — आणि users जिथे ओढतात तिथेच तो वाढवा.
Developer experience (DevEx) — developers ना आपले काम करणे किती सोपे, जलद आणि सुखद वाटते ते. Platform च्या product ची गुणवत्ता इथे दिसते.

🤔 का

कारण platforms अपयशी होण्याचा सर्वात सामान्य मार्ग शांत असतो: ते बनवले जातात, जाहीर होतात, आणि वापरले जात नाहीत. Teams आपल्या स्वतःच्या scripts ठेवतात कारण platform ने त्यांची समस्या सोडवली नाही, किंवा अशा पद्धतीने सोडवली की त्यांचा दिवस जास्त वाईट गेला. आधी users शी बोलणे चुकीची गोष्ट बनवण्यापेक्षा स्वस्त आहे. आणि निवडलेले adoption मोजल्याने महिन्यामागून महिना कळते की कार्यालयाचा खरोखर उपयोग होतो आहे का.

🔧 कसे (या repo मध्ये)

idp/office.py मधले rank_pains(interviews) {team: {pain: hours lost per week}} घेते, प्रत्येक त्रासाचे सगळ्या teams मधले तास बेरीज करते, teams मोजते, आणि आधी तासांनुसार, मग teams च्या संख्येनुसार, मग नावानुसार क्रम लावते (म्हणजे क्रम स्थिर राहतो). adoption(teams, on_path) म्हणजे paved path निवडलेल्या teams ची टक्केवारी. idp/demo.py मधले product() पाच विभागांच्या मुलाखती घेते आणि roadmap आणि महिने 1, 3 आणि 6 मधले adoption छापते.

🧪 करून पाहा

python3 idp/demo.py product
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from office import rank_pains, adoption
interviews = {"science": {"waiting for a database": 6, "writing CI YAML": 3},
              "maths":   {"waiting for a database": 4, "finding a service's owner": 1},
              "library": {"writing CI YAML": 4},
              "sports":  {"finding a service's owner": 1},
              "arts":    {"finding a service's owner": 2}}
print("top pain:", rank_pains(interviews)[0])
interviews["music"] = {"writing CI YAML": 5}          # one more interview
for pain, hours, teams in rank_pains(interviews): print(f"{pain:<26} {hours:>2} h/week · {teams} teams")
teams = list(interviews)
print("adoption with 3 of 6 on the path:", adoption(teams, {"science", "maths", "music"}), "%")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

product हे छापते:

── Dipika (the facilities office) interviews 5 departments: hours lost per week, per pain
   1. waiting for a database     15 h/week across 3 teams
   2. writing CI YAML             7 h/week across 2 teams
   3. finding a service's owner   5 h/week across 4 teams
   4. preview environments        5 h/week across 2 teams
   5. rotating secrets            3 h/week across 2 teams
   month 1:  20% of departments chose the paved path
   month 3:  60% of departments chose the paved path
   month 6:  80% of departments chose the paved path

तुमचा snippet हे छापतो:

top pain: ('waiting for a database', 10, 2)
writing CI YAML            12 h/week · 3 teams
waiting for a database     10 h/week · 2 teams
finding a service's owner   4 h/week · 3 teams
adoption with 3 of 6 on the path: 50 %

🏁 तुम्ही आत्ताच काय सिद्ध केले

आणखी एका मुलाखतीने roadmap चे शिखर बदलले: संगीत विभागामुळे CI YAML (12 h/week) database (10 h/week) च्या पुढे जाते. Roadmap हा ऐकण्याचा परिणाम आहे, आणि तुम्ही जास्त लोकांचे ऐकले की तो बदलतो. "finding a service's owner" कडेही लक्ष द्या: तो 4 teams ना त्रास देतो पण एकूण फक्त 5 तास — अनेकांना थोडासा जाणवणारा त्रास. आधी तासांनुसार आणि मग teams च्या संख्येनुसार क्रम लावणे हा एक निर्णय आहे; खरे कार्यालय त्याला वेगळे वजन देऊ शकते, आणि ते कसा क्रम लावते हे त्याने सांगायला हवे.

📏 शिकवण्याचे मॉडेल: खऱ्या मुलाखती गोष्टी देतात, स्वच्छ आकडे नाहीत. अंदाजे "वाया गेलेले तास" ढोबळ असतात; त्यांचा वापर कामाचा क्रम लावायला करा, अचूक सत्य म्हणून नाही.

⚠️ नेहमीच्या चुका

users ना काय हवे त्याऐवजी platform team ला जे रोचक वाटते ते बनवणे
चांगल्या product ऐवजी सक्ती — adoption वाढतो, समाधान घटते, पळवाटा वाढतात
"what happened last time?" ऐवजी "would you use X?" विचारणे (सगळे हो म्हणतात)
documentation नाही, release notes नाहीत, support channel नाही — हे product आहे, म्हणून तिन्ही हवेत
path सोडणाऱ्या teams ना feedback न मानता नियम मोडणाऱ्या मानणे

🏭 प्रत्यक्ष वापरात

Roadmap कंपनीच्या आत सार्वजनिक ठेवा, म्हणजे प्रत्येक team ला काय येत आहे आणि का ते दिसेल. एक छोटा, प्रामाणिक format — प्रत्येक item साठी एक issue, पुराव्यासह label लावलेला:

# on a real account, with the GitHub CLI, in the platform team's repo
gh issue create --title "Self-service Postgres (roadmap #1)" \
  --label roadmap --label "pain:15h-week" \
  --body "Interviews: science 6 h, sports 5 h, maths 4 h per week waiting for a database."
gh issue list --label roadmap

अनेक platform teams दर तिमाहीला एक छोटे survey सुद्धा घेतात (उदाहरणार्थ: "मागच्या महिन्यात एक बदल ship करणे किती सोपे होते?" 1–5 च्या प्रमाणावर, आणि एक मोकळा प्रश्न). धडा 11 याकडे परत येतो: systems मधले आकडे आणि लोकांची उत्तरे.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: platform ची स्पर्धा "मी स्वतःच करून टाकेन" शी असते. तो स्पष्टपणे सोपा मार्ग असेल तेव्हाच जिंकतो — आणि "सोपा" म्हणजे काय हे फक्त विचारूनच कळते.

⏭️ पुढे

सर्वात मोठा त्रास आहे "प्रत्येक team कोऱ्या पानापासून सुरुवात करते". कार्यालयाचा पहिला संच: एक template जो नव्या service ला एका पायरीत चालणारा सांगाडा देतो.

git checkout lesson-03-golden-paths

🤝 Lesson 02 — Platform as a product: teachers are the office's customers

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-why-platforms · Next: lesson-03-golden-paths

📦 What's in this branch

Lesson 01, plus the mindset that decides whether a platform is used or ignored: treat it as a product. The teams are users. You interview them, rank their pains, build a roadmap from the biggest pain down, and measure adoption — teams that choose the platform — instead of forcing it with a mandate. rank_pains() and adoption() in idp/office.py, product() in idp/demo.py.

🧒 Explain like I'm 5

Dipika runs the facilities office. She has a budget for one new kit this month.

She could build the thing she finds most fun: a shiny smart-board kit. 🖥️ Instead she walks around the school with a notebook and asks each department: "What wastes your time? How many hours a week?"

Science says: "Waiting for a lab database — 6 hours a week."
Maths says: "Waiting for a database — 4 hours. Finding who owns the timetable screen — 1 hour."
Sports says: "Waiting for a database — 5 hours."

She adds it all up. Waiting for a database costs 15 hours a week across the school. That is the first kit. Not the smart board.

Then she does not order anyone to use it. She makes it so good that departments want it. She counts how many choose it: 1 of 5 in month 1, 3 of 5 in month 3, 4 of 5 in month 6. When the arts department says "no thanks", she asks why — that answer is her next job.

🗺️ Diagram

flowchart LR
    i["🗣️ interviews<br/>5 departments"] --> r["📊 rank by hours lost<br/>database 15 h/week<br/>CI YAML 7 · owner lookup 5"]
    r --> m["🗺️ roadmap<br/>biggest pain first"]
    m --> b["🧰 build the kit"]
    b --> a["📈 adoption<br/>20% → 60% → 80%"]
    a -->|"teams that leave: ask why"| i

🗺️ Drawn version + a lab: https://school-edh.pages.dev/platform-engineering/lesson-diagrams.html#l02

❓ What

Platform as a product — the platform team works like a product team: it has users, does user research, keeps a public roadmap, writes documentation and release notes, and measures whether users are better off. The CNCF Platforms White Paper and Team Topologies both describe platforms this way.
Users (internal customers) — the developers and teams who build on the platform. They usually can go around it (write their own Terraform, use a cloud console), so the platform must earn its place.
User interviews — talking to users about their work and their pains, not asking "would you like feature X?" Good questions are about the past: "Last time you needed a database, what happened?"
Roadmap — the ordered list of what the office will build. Ranked by value (here: hours lost per week, then how many teams feel it), not by what is fun to build.
Adoption — the share of teams that use the platform. When use is voluntary, adoption is honest feedback. A mandate ("everyone must use it by Q3") makes the number go up without telling you whether the product is good.
Thinnest viable platform (TVP) — a Team Topologies idea: start with the smallest thing that helps — even a wiki page of good defaults — and grow it only where users pull.
Developer experience (DevEx) — how easy, fast and pleasant it is for developers to get their work done. The platform's product quality shows up here.

🤔 Why

Because the most common way platforms fail is quietly: they are built, announced, and not used. Teams keep their own scripts because the platform did not solve their problem, or solved it in a way that made their day worse. Talking to users first is cheaper than building the wrong thing. And measuring chosen adoption tells you, month by month, whether the office is actually helping.

🔧 How (in this repo)

rank_pains(interviews) in idp/office.py takes {team: {pain: hours lost per week}}, adds the hours per pain across teams, counts the teams, and sorts by hours, then by team count, then by name (so the order is stable). adoption(teams, on_path) is the percentage of teams that chose the paved path. product() in idp/demo.py interviews five departments and prints the roadmap and adoption at months 1, 3 and 6.

🧪 Try it

python3 idp/demo.py product
python3 - <<'EOF'
import sys; sys.path.insert(0, "idp"); from office import rank_pains, adoption
interviews = {"science": {"waiting for a database": 6, "writing CI YAML": 3},
              "maths":   {"waiting for a database": 4, "finding a service's owner": 1},
              "library": {"writing CI YAML": 4},
              "sports":  {"finding a service's owner": 1},
              "arts":    {"finding a service's owner": 2}}
print("top pain:", rank_pains(interviews)[0])
interviews["music"] = {"writing CI YAML": 5}          # one more interview
for pain, hours, teams in rank_pains(interviews): print(f"{pain:<26} {hours:>2} h/week · {teams} teams")
teams = list(interviews)
print("adoption with 3 of 6 on the path:", adoption(teams, {"science", "maths", "music"}), "%")
EOF

✅ Verify — what you should see

product prints:

── Dipika (the facilities office) interviews 5 departments: hours lost per week, per pain
   1. waiting for a database     15 h/week across 3 teams
   2. writing CI YAML             7 h/week across 2 teams
   3. finding a service's owner   5 h/week across 4 teams
   4. preview environments        5 h/week across 2 teams
   5. rotating secrets            3 h/week across 2 teams
   month 1:  20% of departments chose the paved path
   month 3:  60% of departments chose the paved path
   month 6:  80% of departments chose the paved path

Your snippet prints:

top pain: ('waiting for a database', 10, 2)
writing CI YAML            12 h/week · 3 teams
waiting for a database     10 h/week · 2 teams
finding a service's owner   4 h/week · 3 teams
adoption with 3 of 6 on the path: 50 %

🏁 What you just proved

One more interview changed the top of the roadmap: with the music department, CI YAML (12 h/week) passes the database (10 h/week). The roadmap is a result of listening, and it moves when you listen to more people. Note also "finding a service's owner": it hurts 4 teams but only 5 hours in total — a pain many people feel a little. Ranking by hours first and team count second is one choice; a real office might weigh it differently, and should say how it ranks.

📏 Teaching model: real interviews give stories, not clean numbers. Estimated "hours lost" are rough; use them to order the work, not as exact truth.

⚠️ Common mistakes

building what the platform team finds interesting instead of what users need
a mandate instead of a better product — adoption rises, satisfaction falls, workarounds grow
asking "would you use X?" (everyone says yes) instead of "what happened last time?"
no documentation, no release notes, no support channel — it is a product, so it needs all three
treating teams that leave the path as rule-breakers instead of as feedback

🏭 In production

Keep the roadmap public inside the company, so every team sees what is coming and why. A minimal, honest format — one issue per item, labelled with the evidence:

# on a real account, with the GitHub CLI, in the platform team's repo
gh issue create --title "Self-service Postgres (roadmap #1)" \
  --label roadmap --label "pain:15h-week" \
  --body "Interviews: science 6 h, sports 5 h, maths 4 h per week waiting for a database."
gh issue list --label roadmap

Many platform teams also run a short survey every quarter (for example: "How easy was it to ship a change last month?" on a 1–5 scale, plus one free-text question). Lesson 11 comes back to this: numbers from systems and answers from people.

🏭 Why this matters in production: the platform competes with "I'll just do it myself". It wins only when it is clearly the easier path — and you only learn what "easier" means by asking.

⏭️ Next

The top pain is "every team starts from a blank page". The office's first kit: a template that gives a new service a working skeleton in one step.

git checkout lesson-03-golden-paths

← Previouswhy platforms Next →golden paths

This page is the lesson's README from the lesson-02-platform-as-product branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.