EVSecure: Problem Discovery & Strategy

Build a PM case study on EV battery security using TARA threat modeling.

Introduction

30 Second Summary

Electric vehicles with Bluetooth-connected batteries are being remotely shut down mid-ride by strangers standing just a few meters away. What started as viral videos in July 2026 has exposed a systemic security gap affecting thousands of vehicles on the road today.

In this project, you will build a professional Product Management case study that takes you from investigating real security incidents through to a complete product strategy for EVSecure, a Bluetooth security layer for electric vehicle batteries.

What You'll Build

A full problem discovery and product strategy package covering threat modeling, user personas, journey mapping, and product vision for a BLE-enabled Battery Management System security product.

By the end of this project, you'll have:

A problem discovery brief anchored in 4 real-world EV security incidents with a complete TARA threat model aligned to ISO/SAE 21434.
Three user personas built using the Jobs-to-Be-Done framework, each validated against specific threats from your analysis.
A complete product strategy including an Opportunity Solution Tree, North Star Metric, and product vision statement ready for interview presentation.
Secret Mission: A competitive positioning map evaluating existing BMS security solutions and positioning EVSecure's unique differentiation.

Are there any prerequisites?

You will need free accounts for Notion (for structured documentation) and Miro (for visual mapping). Both offer free plans that cover everything in this project.

No coding or prior PM experience is required. Basic familiarity with creating documents is all you need to get started.

Set Up Your PM Workspace

A well-organized workspace is the foundation of any PM case study. When presenting to interviewers, having clearly separated artifacts shows structured thinking before you even discuss content.

In this step, you will create a Notion workspace for your written artifacts and a Miro board for your visual frameworks.

In this step, get ready to:

Create a structured Notion page with 5 sub-pages mirroring the product development lifecycle.
Set up a Miro board with 4 named frames for visual artifacts.
Verify both workspaces are accessible and ready for content.

Create your Notion case study structure

PMs organize work in a hierarchy that mirrors the product development lifecycle. Discovery comes first because you cannot design solutions without deeply understanding problems.

In your Notion sidebar, click New page at the top of the left sidebar.
Title the new page EVSecure - PM Case Study.
Open the page by clicking on it in the sidebar.
Inside the page, type /page and press Enter to create a sub-page.
Title this sub-page Problem Discovery & Market Context.
Repeat the /page command to create 4 more sub-pages with these exact titles:

Why this structure?

Each section becomes a standalone artifact you can present in interviews. Discovery comes first because interviewers look for whether you can distinguish "interesting technology" from "real user problem worth solving."

This hierarchy also mirrors how real PM teams organize work. Starting with problem discovery prevents the most common PM mistake: jumping to solutions before understanding the problem.

Your Notion sidebar should now show the EVSecure - PM Case Study page with 5 nested sub-pages beneath it.

Don't see your sub-pages?

Make sure you created the sub-pages while inside the parent page. If they appear at the top level of your sidebar instead of nested, drag them onto the EVSecure - PM Case Study page to nest them.

If the /page command does not appear, try clicking into an empty area of the page body first, then type the slash command.

help me set up sub-pages in Notion for my PM case study

Set up your Miro board

Journey maps and opportunity trees are spatial artifacts. PMs use Miro for these because stakeholders grasp visual relationships faster than text hierarchies.

In your Miro dashboard, click + Create new.
Click Board from the menu that opens.
Click the board title at the top left of the canvas and rename it to EVSecure - Discovery & Strategy.

Now create 4 frames to organize your visual work.

Click the Frame icon in the Creation toolbar on the left side of your board.
Click and drag on the board to create your first frame.
Double-click the frame title area and name it Threat Landscape.
Create 3 more frames using the same method, naming them:

Use the F hotkey

Press F on your keyboard to activate the Frame tool quickly. Then click anywhere on the board to place a frame without needing to find the icon each time.

Why Miro instead of Notion for these artifacts?

Notion is for structured text. Miro is for visual thinking and workshop-style collaboration.

Journey maps require spatial layout with swim lanes. Opportunity Solution Trees are literal tree diagrams. Positioning maps need 2D axes. These artifacts lose their power when forced into linear text documents.

Your Miro board should now show 4 distinct frames arranged on the canvas, each with a visible title.

Frames not appearing?

Make sure you are clicking the Frame icon (looks like a rectangle with corner marks) in the left toolbar. It is different from the Shapes tool.

If your board opened with a template picker, close it by clicking outside the modal or selecting a blank board option.

help me create frames on my Miro board

Verify your setup

Switch back to Notion and expand your EVSecure - PM Case Study page in the sidebar.
Confirm you see all 5 sub-pages nested beneath it.
Switch to your Miro board and confirm all 4 frames are visible with their titles.

Your workspace is ready. Next up, you will dive into the real-world incidents that prove EVSecure's problem exists and apply the TARA threat modeling framework to structure your findings.

Build Your Problem Discovery and Threat Model

Your workspace is set up and ready. Now it is time to fill it with the evidence that proves a real problem exists and a structured framework to analyze how serious it is.

In this step, you will document 4 real-world security incidents affecting BLE-enabled electric vehicles. You will then apply the TARA threat modeling framework from ISO/SAE 21434 to structure your analysis into an interview-ready artifact.

In this step, get ready to:

Document 4 real-world BMS security incidents with a structured problem statement in Notion.
Apply the 5-step TARA threat modeling framework in both Miro and Notion.
Synthesize the regulatory context (UNECE R155 and ISO/SAE 21434) to establish why this problem demands a product response now.

Document the problem space

Problem framing is the most critical PM skill. You need credible evidence that a problem exists, it is growing, and it affects identifiable users.

Switch back to your Notion workspace and open the Problem Discovery & Market Context sub-page.
Type /heading and select Heading 1 to create a heading titled Problem Statement.

Below the heading, add the following four sections as bold labels with your answers. This template captures the essential dimensions of any PM problem statement.

Who is affected: Riders, drivers, and fleet operators of BLE-enabled electric vehicles (e-rickshaws, e-scooters, EVs with Bluetooth BMS).
What is happening: Unauthorized users within 10-15 meters Bluetooth range can connect to unprotected BMS units and disable battery discharge, causing sudden loss of power mid-ride.
Why it matters now: BAT-BMS viral incidents (July 2026) demonstrated real-world exploitation. Regulatory pressure from UNECE R155 (mandatory for new vehicle types since July 2024) and ISO/SAE 21434 requiring lifecycle cybersecurity.
Scale of impact: Thousands of e-rickshaws with unsecured BLE-enabled BMS on Indian roads. BMS units costing $8-$15 wholesale with authentication as the first cost-cut.

Why start with a problem statement?

Interviewers look for whether you can distinguish "interesting technology" from "real user problem worth solving." This four-part template forces you to articulate who, what, why now, and how big. If you cannot fill each section with evidence, you do not yet have a validated problem.

Now add an incident evidence table below your problem statement. This provides the concrete proof backing your claims.

Type /table in Notion and select Table - Inline to insert a simple table.
Create 5 columns: Incident, Date, Attack Vector, Impact, Source.
Add 4 rows using the data below.

Here is the content for each row of your incident evidence table:

Row 1: BAT-BMS e-rickshaw shutdowns | June-July 2026 | Unauthenticated BLE connection to BMS within 15m | Battery discharge disabled mid-ride, sudden power loss | Viral social media videos, Autocar Professional reporting.
Row 2: E-Trojans (Xiaomi M365/ES3) | 2024 research paper | BMS remote code execution via malicious app or BLE proximity | Battery ransomware (50% autonomy loss in 3hrs), user tracking | Academic paper arxiv 2411.17184.
Row 3: CVE-2025-5749 (WOLFBOX EV Charger) | June 2025 | Uninitialized variable in BLE cryptographic key handling | Authentication bypass, CVSS 8.8 High | NVD/Zero Day Initiative (ZDI-25-328).
Row 4: Pwn2Own Automotive 2024 (Autel MaxiCharger) | January 2024 | Hardcoded auth token in firmware + stack buffer overflows via BLE | Arbitrary code execution from BLE range only | Sector 7/Computest research, CVE-2024-23958/23959/23967.

What does this table prove?

Each incident demonstrates a different facet of BLE-BMS vulnerability: no authentication (BAT-BMS), firmware-level exploits (E-Trojans), cryptographic implementation flaws (WOLFBOX), and hardcoded credentials (Autel). Together, they show this is a systemic class of problem, not an isolated bug.

Your evidence spans 2024-2026, proving the problem is persistent and escalating. This pattern recognition is what separates a strong PM case study from a feature request.

Your Notion page should now show a structured problem statement followed by a 4-row evidence table. Leave this page open for later.

Apply TARA threat modeling

TARA stands for Threat Analysis and Risk Assessment. It is the industry-standard framework defined in ISO/SAE 21434 Clause 15 that automotive companies are required to perform for every component with cybersecurity relevance.

Why TARA instead of a generic threat model?

Unlike generic threat models, TARA is the specific framework that automotive regulators (UNECE R155) expect as compliance evidence. Using it demonstrates domain expertise and shows you understand the regulatory context your product operates in.

A generic STRIDE analysis alone would be insufficient for this domain. TARA wraps STRIDE-style threats inside a risk-rated, treatment-oriented process that regulators can audit.

You will build the TARA model visually in Miro and also document it as structured text in Notion. Start with the visual version.

Switch back to your Miro board and navigate to the Threat Landscape frame.
Click the sticky note icon in the Creation toolbar on the left (or press N) to add sticky notes for each section heading.
Create 5 section headings as sticky notes: Step 1: Asset Identification, Step 2: Threat Scenarios, Step 3: Impact Rating, Step 4: Attack Paths, Step 5: Risk Determination.

Now populate each section. Use sticky notes for list items and a Grid or Table for structured data.

For Step 1 (Asset Identification), add sticky notes listing these 5 assets:

BLE communication channel (BMS to mobile app).
BMS firmware and configuration registers.
Authentication credentials/pairing keys.
Battery state data (SOC, voltage, temperature).
Discharge/charge control commands.

For Step 2 (Threat Scenarios), add sticky notes using STRIDE categories:

Spoofing: Attacker impersonates authorized user to BMS.
Tampering: Attacker modifies BMS discharge settings.
Repudiation: No audit trail of who issued commands.
Information Disclosure: Battery data leaked to nearby devices.
Denial of Service: Battery discharge disabled mid-operation.
Elevation of Privilege: Attacker gains owner-level control without authentication.

For Step 3 (Impact Rating), create a table in Miro. Click the Tools, Media and Integrations (+) icon in the Creation toolbar, search for Grid, and place a grid with 5 columns and 5 rows inside your frame.

Fill in the impact rating table with these values (per ISO/SAE 21434 Annex H dimensions):

Headers: Threat | Safety | Financial | Operational | Privacy | Overall.
Unauthorized discharge disable: Severe | Major | Severe | Negligible | Severe.
BMS firmware manipulation: Severe | Severe | Severe | Moderate | Severe.
Data exfiltration (battery telemetry): Negligible | Moderate | Negligible | Major | Major.
User tracking via BLE fingerprinting: Negligible | Negligible | Negligible | Severe | Severe.

For Step 4 (Attack Paths), add 3 sticky notes describing each path:

Path 1: Attacker downloads BAT-BMS app, scans for BLE devices within 15m, connects to unprotected BMS, disables discharge. Feasibility: Very High (no technical skill required).
Path 2: Attacker reverse-engineers BMS firmware, extracts hardcoded credentials, builds custom BLE exploit. Feasibility: Medium (requires technical expertise).
Path 3: Malicious app on victim's phone exploits BMS via authenticated connection. Feasibility: Medium (requires social engineering to install app).

For Step 5 (Risk Determination and Treatment), add sticky notes with:

Unauthorized BLE access: Risk = Critical. Treatment = Reduce (implement mutual authentication + OTP).
Firmware manipulation: Risk = High. Treatment = Reduce (encrypted firmware + secure boot).
Data leakage: Risk = Medium. Treatment = Reduce (encrypted BLE communication).
Tracking: Risk = Medium. Treatment = Reduce (BLE address randomization).

Arrange visually for readability

Position the 5 sections left-to-right or top-to-bottom within the Threat Landscape frame. Use different sticky note colors for each TARA step so the visual hierarchy is immediately clear to a stakeholder viewing your board.

Now duplicate this analysis into your Notion page for the text-based version.

Switch back to Notion and open the Threat Model (TARA) sub-page.
Create a Heading 1 titled TARA Threat Analysis (ISO/SAE 21434 Clause 15).
Add Heading 2 sections for each of the 5 steps (Asset Identification, Threat Scenarios, Impact Rating, Attack Paths, Risk Determination & Treatment).
Copy the same content from your Miro sticky notes into each section. Use bullet lists for Steps 1, 2, 4, and 5. Use an inline table for Step 3 (the impact rating matrix).

Why document in both Miro and Notion?

Miro is your visual artifact for stakeholder presentations and workshops. Notion is your structured reference document for written communication. PMs maintain both because different audiences consume information differently. A VP wants the visual overview. An engineer wants the detailed text.

Verify that your Miro frame shows all 5 TARA steps with content, and your Notion sub-page has the matching structured text.

Grid not appearing in Miro?

If you cannot find the Grid tool, click the + icon in the Creation toolbar and type Grid in the search field. You can also use sticky notes arranged in a grid pattern as an alternative. The content matters more than the exact visual format.

Help me set up a TARA table in my Miro board.

Synthesize into regulatory context

Your threat model shows what can go wrong. The regulatory context explains why the market must respond. Together, they form the urgency case for EVSecure.

Switch back to Notion and return to the Problem Discovery & Market Context sub-page.
Scroll to the bottom and add a Heading 1 titled Regulatory Landscape.
Add the following three sections as Heading 2 entries with explanatory text below each.

UNECE R155: Mandatory for all new vehicle type approvals in EU since July 2024. Requires a Cybersecurity Management System (CSMS) with risk assessment, proportionate mitigations, and annual monitoring reports. Cryptographic modules must align with consensus standards.

ISO/SAE 21434: The engineering standard that provides the "how" for R155 compliance. TARA (Clause 15) is mandatory for every cybersecurity-relevant component. External interfaces including Bluetooth are explicitly in scope.

Market Gap: Low-cost BMS manufacturers (primarily Chinese suppliers competing on price at $8-$15/unit) are shipping without authentication. EVSecure fills the gap between regulatory intent and market reality.

Type each of these three sections into your Notion page under the Regulatory Landscape heading.

Why does the regulatory context matter for a PM?

Regulations create market urgency. When compliance becomes mandatory (UNECE R155 since July 2024), companies that previously ignored security are forced to act. This transforms EVSecure from a "nice to have" into a compliance necessity. PMs who understand regulatory timelines can time their product to meet demand at the moment it becomes acute.

Your Problem Discovery & Market Context page should now have three major sections: Problem Statement, Incident Evidence Table, and Regulatory Landscape.

Your problem discovery is complete. Next up, you will build user personas using the Jobs-to-Be-Done framework to connect these threats to real people with real motivations.

Create User Personas with Jobs-to-Be-Done

Your problem discovery is now grounded in real incidents, and your TARA threat model identifies exactly where BLE-enabled BMS systems are vulnerable. The next question is: who suffers most from these vulnerabilities?

In this step, you'll build user personas using the Jobs-to-Be-Done (JTBD) framework. Each persona captures what the user is trying to accomplish and why security failures block that goal.

In this step, get ready to:

Document why JTBD is the right framework for this case study.
Create 3 user personas with JTBD statements, pain points, and success metrics.
Validate each persona against your TARA threat model.

Understand why JTBD over demographic personas

The JTBD framework focuses on what users are trying to accomplish and why. The format is: "When [situation], I want to [motivation], so I can [expected outcome]."

Your three personas span very different demographics (an e-rickshaw driver, a service technician, a fleet manager). JTBD reveals their shared motivation: all three need authorized-only BMS access, but for different reasons.

In Notion, open your User Personas sub-page (it's currently empty).
At the top of the page, create a heading called Framework Decision - Why JTBD.
Add the following text below the heading:

JTBD describes WHAT the user is trying to accomplish and WHY. PMs prefer JTBD because it reveals the motivation behind behavior. Two users with completely different demographics may have the same Job to be Done.
JTBD format: "When [situation], I want to [motivation], so I can [expected outcome]."
When PMs use JTBD: During discovery, to ensure you are solving real motivations rather than assumed needs. It prevents the trap of building features that map to personas on paper but don't match what people actually need to accomplish.

Why does this framework choice matter for interviews?

PM interviewers look for whether you can explain your framework choices. Documenting WHY you chose JTBD shows structured thinking.

It also demonstrates awareness that persona quality depends on methodology, not just filling in a template.

Create 3 JTBD-based personas

Each persona needs five sections: Context, Primary JTBD, Secondary JTBD, Pain Points, and Success Metric. These sections ground the persona in the real-world problem you documented in Step 2.

Below your Framework Decision section, create a new heading: Persona 1: Ramesh - E-Rickshaw Owner/Driver.
Add the following content under this heading:

Context: Owns a single e-rickshaw for passenger transport in urban India. Relies on daily income from rides. Has a BLE-enabled lithium battery pack with BMS.
Primary JTBD: "When I am driving passengers through traffic, I want to be certain my battery cannot be remotely disabled, so I can complete my rides safely and earn my daily income without fear of sudden power loss."
Secondary JTBD: "When I charge my battery overnight, I want to easily check its health status on my phone, so I can catch degradation early and avoid expensive replacements."
Pain Points: Heard about viral BAT-BMS videos and is anxious. Does not understand Bluetooth security. Cannot afford expensive solutions. Needs something that works without technical knowledge.
Success Metric: Zero unauthorized disconnection events during operation.

What makes Ramesh's JTBD effective?

Notice how the JTBD statement names the situation (driving in traffic), the motivation (certainty of no remote disable), and the outcome (safe rides and daily income). It connects the security problem directly to livelihood impact.

Create a new heading: Persona 2: Priya - EV Service Technician.
Add the following content:

Context: Works at a multi-brand EV service center. Diagnoses battery issues across 10+ battery brands daily. Needs BLE access to BMS for diagnostics but serves vehicles she does not own.
Primary JTBD: "When I am diagnosing a customer's battery issue, I want temporary authenticated access to their BMS data, so I can identify faults quickly without the customer worrying I might misuse access."
Secondary JTBD: "When a diagnostic session ends, I want access to automatically expire, so I am not liable if something happens to the vehicle later."
Pain Points: Currently uses same unrestricted apps (BAT-BMS, Jiabaida, Xiaoxiang) as everyone else. No audit trail of her actions. Customers are increasingly suspicious. Needs to prove she only read data, did not modify settings.
Success Metric: Average diagnostic time stays under 15 minutes while maintaining full audit trail.

Create a new heading: Persona 3: Vikram - Fleet Manager.
Add the following content:

Context: Manages 200+ e-rickshaws for a ride-sharing company. Responsible for uptime, safety compliance, and cost optimization. Reports to operations director.
Primary JTBD: "When any vehicle in my fleet is at risk of unauthorized BMS access, I want to be alerted immediately, so I can take action before a safety incident occurs and before regulators ask questions."
Secondary JTBD: "When preparing compliance reports, I want a dashboard showing all BMS access events across my fleet, so I can demonstrate due diligence to regulators and insurers."
Pain Points: Has no visibility into which vehicles have unsecured BMS. Cannot enforce security policies across heterogeneous battery brands. One incident could shut down operations and trigger regulatory scrutiny.
Success Metric: Fleet-wide unauthorized access attempts reduced by 90%. Compliance audit time reduced by 75%.

Why three personas with different roles?

Ramesh represents the end user (direct safety impact). Priya represents the service layer (access control complexity). Vikram represents the business buyer (fleet-wide risk and compliance).

In PM interviews, showing three distinct user types with different motivations proves you can think beyond a single "target user" and understand the full ecosystem around a product.

Validate personas against TARA

Personas disconnected from your threat model are fiction. By mapping each persona to specific threats from your TARA analysis, you prove your user definitions are grounded in the real problem.

At the bottom of your User Personas page, create a heading: Persona-to-TARA Validation.
Create a table with four columns: Persona, Most Relevant Threat, Impact Dimension, and Risk Tolerance.
Fill in the table with the following data:

Ramesh (Owner): Most Relevant Threat = Unauthorized discharge disable. Impact Dimension = Safety + Operational. Risk Tolerance = Zero tolerance (livelihood at stake).
Priya (Technician): Most Relevant Threat = Repudiation (no audit trail). Impact Dimension = Financial + Operational. Risk Tolerance = Low tolerance (professional reputation).
Vikram (Fleet Manager): Most Relevant Threat = Elevation of privilege at scale. Impact Dimension = Financial + Operational. Risk Tolerance = Zero tolerance (regulatory + business risk).

Why validate personas against the threat model?

This cross-reference creates a traceable link from technical analysis (TARA) to human impact (personas). When an interviewer asks "how do you know these are the right users?", you can point to specific threats that affect each persona differently.

It also reveals that Ramesh faces safety threats (life-threatening), while Priya faces reputation threats, and Vikram faces regulatory threats. Different threat types demand different product responses.

Review your completed User Personas page. You should see: a Framework Decision note at the top, three full personas each with Context, Primary JTBD, Secondary JTBD, Pain Points, and Success Metric, and a validation table at the bottom.

Personas feel too similar?

Check that each persona's Primary JTBD names a different situation and a different expected outcome. If two personas share the same outcome, their pain points and success metrics should clearly diverge.

Help me differentiate my JTBD personas for a security product

You now have three personas that are grounded in your threat model and driven by real motivations. Next up, you'll map Ramesh's current broken experience as a journey map to reveal exactly where EVSecure can intervene.

Map User Journeys in Miro

Your personas define who is affected by BLE-enabled BMS vulnerabilities. Now you need to map when and where the experience breaks for them.

User journey mapping is a technique PMs use to visualize the step-by-step experience a user goes through. By mapping Ramesh's current broken experience and then mapping what his experience could look like with EVSecure, you'll pinpoint the exact moments where your product needs to intervene.

In this step, get ready to:

Create a current-state journey map showing Ramesh's broken experience today.
Create a future-state journey map showing Ramesh's experience with EVSecure.
Extract 4 opportunity moments that bridge discovery to product design.

Map the current-state journey (the problem journey)

You cannot design a better future without documenting what is broken today. The current-state journey reveals specific moments of failure that become your design opportunities.

You'll build a horizontal journey map for Ramesh (your EV Owner persona) using swim lanes. Each row tracks a different dimension of his experience across 5 stages.

Switch to your Miro board "EVSecure - Discovery & Strategy" from earlier.
Navigate to the User Journey Maps frame (Frame 2).
Add a heading at the top of the frame: "Current-State Journey - Ramesh (E-Rickshaw Owner)".
Create a table or grid with 5 columns (one per stage) and 5 rows (one per swim lane).

Your 5 swim lanes are: Stage, Action, Touchpoint, Emotion, and Pain Point. Fill in the following data across each of the 5 stages:

Stage 1 - Daily Setup:

Action: Turns on e-rickshaw, begins driving.
Touchpoint: Vehicle, battery, road.
Emotion: Neutral / slightly anxious.
Pain Point: Has heard about BMS hacking but doesn't know if he's vulnerable.

Stage 2 - Mid-Ride:

Action: Stranger within 15m opens BAT-BMS app and connects to his BMS.
Touchpoint: Attacker's phone, BLE signal.
Emotion: Unaware.
Pain Point: BMS has no authentication. Connection happens silently.

Stage 3 - Attack:

Action: Attacker disables battery discharge function.
Touchpoint: BMS registers, BLE command.
Emotion: Unaware turning to panic.
Pain Point: No notification, no warning, no consent required.

Stage 4 - Impact:

Action: E-rickshaw loses power mid-traffic.
Touchpoint: Vehicle, traffic, passengers.
Emotion: Fear, anger, helplessness.
Pain Point: Stranded in traffic, passengers at risk, income lost.

Stage 5 - Recovery:

Action: Must find technician to re-enable discharge.
Touchpoint: Service center, lost time.
Emotion: Frustration, financial stress.
Pain Point: Pays for fix, loses half-day income, no way to prevent recurrence.

Arrange the 5 stages as columns flowing left to right across your Miro frame.
Use color-coded sticky notes or shapes for the Emotion row to show the emotional arc (neutral to panic to frustration).

Why PMs map current-state first

The current-state journey reveals specific moments of failure. These moments become your design opportunities.

Interviewers want to see that you identified WHERE the experience breaks, not just THAT it breaks. Each stage in Ramesh's journey is a potential intervention point for your product.

Map the future-state journey (EVSecure experience)

Now you'll map what Ramesh's experience looks like with EVSecure protecting his BMS. This shows stakeholders the tangible value your product delivers at every stage.

Below your current-state map in the same Miro frame, add a new heading: "Future-State Journey - Ramesh with EVSecure".
Create the same grid structure: 5 columns and 5 rows.
The swim lanes for this map are: Stage, Action, Touchpoint, Emotion, and EVSecure Feature.

Fill in the following data across the 5 stages:

Stage 1 - Onboarding:

Action: Pairs his phone to BMS via EVSecure app.
Touchpoint: EVSecure app, QR code on battery.
Emotion: Confident, in control.
EVSecure Feature: Secure device pairing (one-time QR + PIN).

Stage 2 - Daily Setup:

Action: Starts driving, sees "Protected" badge in app.
Touchpoint: EVSecure notification.
Emotion: Reassured.
EVSecure Feature: Background BLE monitoring active.

Stage 3 - Attempted Attack:

Action: Stranger tries to connect to BMS.
Touchpoint: Attacker's phone, BLE signal.
Emotion: Unaware (system handles it).
EVSecure Feature: BLE connection rejected (mutual authentication fails).

Stage 4 - Alert:

Action: Gets push notification: "Unauthorized access attempt blocked".
Touchpoint: EVSecure app alert.
Emotion: Informed, protected.
EVSecure Feature: Intrusion detection + real-time alert.

Stage 5 - Continuity:

Action: Continues driving without interruption.
Touchpoint: Vehicle operates normally.
Emotion: Trust, confidence.
EVSecure Feature: Secure BLE encryption prevents command injection.

Use a visually distinct color scheme for this future-state map to differentiate it from the current-state map above.
Align the columns vertically with the current-state map so stakeholders can compare the two journeys side by side.

Why two maps, not one?

Placing the current-state and future-state journeys above and below each other creates a visual before-and-after. Stakeholders instantly see the emotional arc shifting from "panic and helplessness" to "informed and confident."

This contrast is your strongest persuasion tool in product reviews. It shows the value gap your product fills.

Identify opportunity moments

By comparing the two maps, you can extract the key moments where EVSecure transforms the experience. These opportunity moments become the direct input to your product strategy in the next step.

In the space between your two journey maps, add 4 sticky notes (one per opportunity moment).
Use a bright, contrasting color so the opportunities stand out visually between the two maps.

Add these 4 opportunity moments to your sticky notes:

Silent Connection Problem: Currently, BLE connections happen without any user awareness. Opportunity: Make every connection attempt visible and require consent.
No Identity Layer: Currently, BMS treats all BLE connections identically. Opportunity: Introduce role-based identity (Owner vs. Technician vs. Fleet Manager) with different permission levels.
No Recovery Path: Currently, after an attack, the user has no tools to understand what happened. Opportunity: Provide audit logs and incident reports.
No Proactive Protection: Currently, protection is purely reactive (user discovers the problem after power loss). Opportunity: Real-time monitoring and pre-emptive blocking.

Why PMs extract opportunity moments

These opportunity moments become the input to your Opportunity Solution Tree in the next step. They bridge "here is what is wrong" to "here is where we can intervene."

Each opportunity moment is a potential feature area. Without extracting them explicitly, you risk jumping straight to solutions without articulating the problem space.

Finally, update your Notion workspace to link back to this Miro work:

Return to your Notion page "EVSecure - PM Case Study".
Open the User Journey Maps (link to Miro) sub-page.
Paste the URL of your Miro board and add a note: "Journey maps are in Frame 2 - User Journey Maps."

Keep your artifacts linked

PMs maintain a single source of truth with clear cross-references. When a stakeholder reads your Notion doc, they should be one click away from the visual artifacts in Miro.

Verify your Miro frame shows two journey maps stacked vertically with 4 opportunity sticky notes between them.
Verify your Notion sub-page contains the Miro board link.

Journey maps looking cluttered?

If your maps feel cramped, zoom out in Miro and increase the spacing between columns. Journey maps need breathing room to be readable.

Make sure each swim lane row has consistent height across all 5 stages. How can I make my Miro journey map easier to read?

Your journey maps now show the full before-and-after story. Next up, you'll turn those 4 opportunity moments into a structured product strategy with a vision statement, Opportunity Solution Tree, and North Star Metric.

Define Product Vision, OST, and North Star Metric

Your journey maps revealed exactly where the current experience breaks and where EVSecure can intervene. Those four opportunity moments are the raw material for product strategy.

In this step, you'll translate those insights into a cohesive strategy package. You'll write a product vision, build an Opportunity Solution Tree connecting your outcome to testable experiments, and define the metrics that measure product success.

In this step, get ready to:

Define the EVSecure product vision using Geoffrey Moore's template.
Build a 4-level Opportunity Solution Tree in Miro.
Set a North Star Metric with 5 supporting input metrics.

Define product vision

A product vision statement aligns engineering, design, sales, and leadership around a shared understanding of what you are building and why it is different. In PM interviews, a crisp vision shows you can articulate product value clearly.

You'll use the Geoffrey Moore positioning template, which is the industry-standard structure for articulating product differentiation.

Switch back to Notion and open your Product Vision & Strategy sub-page.
Add a heading called Product Vision.
Type the following vision statement using the Geoffrey Moore template:

For: Owners, technicians, and fleet managers of BLE-enabled electric vehicles.
Who: Face unauthorized Bluetooth access to their Battery Management Systems, risking safety incidents, revenue loss, and regulatory non-compliance.
EVSecure is: A BLE security layer for Battery Management Systems.
That: Prevents unauthorized access through mutual authentication, role-based access control, encrypted communication, and real-time intrusion detection.
Unlike: Current BMS implementations that ship with no authentication, hardcoded credentials, or single-factor security.
Our product: Delivers automotive-grade BLE security (aligned with UNECE R155 and ISO/SAE 21434) in a lightweight, retrofittable module that works across BMS brands without requiring hardware replacement.

Why use a positioning template?

The Geoffrey Moore template forces you to name your target user, the problem, the product category, key differentiators, and competitive context in a single structured statement.

When stakeholders ask "what is this product?" you can answer with one paragraph instead of a 30-slide deck. Interviewers look for whether you can communicate product value crisply.

Build the Opportunity Solution Tree

The Opportunity Solution Tree (created by Teresa Torres) is a visual tool that shows how your desired outcome connects through opportunities to testable solutions. It prevents the common PM trap of jumping to solutions before understanding the opportunity space.

Switch back to Miro and navigate to your Opportunity Solution Tree frame (Frame 3).

You'll build a 4-level tree. Start at the top with your desired outcome and work downward.

Create a sticky note or text box at the top of the frame with your Desired Outcome:

"Reduce unauthorized BMS access by 90% within 12 months of deployment."

Below the desired outcome, add 4 Opportunity nodes. These come directly from your journey map opportunity moments:

Opportunity 1: BLE connections happen without user awareness or consent.
Opportunity 2: BMS has no identity/role differentiation.
Opportunity 3: No audit trail or recovery path after incidents.
Opportunity 4: No real-time detection or proactive protection.

Draw connector lines from the Desired Outcome down to each Opportunity.
Below each Opportunity, add Solution nodes with the following:

Under Opportunity 1: Secure device pairing with QR + PIN. OTP-based session authentication.
Under Opportunity 2: RBAC (Owner/Technician/Fleet Manager). Time-limited technician tokens.
Under Opportunity 3: Encrypted audit logs. Incident report generation. Compliance dashboard.
Under Opportunity 4: Real-time BLE monitoring. Anomaly detection. Push alert system.

Draw connector lines from each Opportunity down to its Solutions.
Add the final level: Experiments below each Solution. These describe how you would validate the solution:

Under Secure Pairing: Prototype pairing flow with 10 e-rickshaw owners, measure completion rate and time.
Under RBAC: Card sort exercise with fleet managers to validate role definitions.
Under Audit Logs: Show mockup to 5 fleet managers, ask if it satisfies their compliance needs.
Under Intrusion Detection: Deploy BLE monitor on 20 vehicles for 2 weeks, measure false positive rate.

Draw connector lines from each Solution down to its Experiment.

Why PMs use Opportunity Solution Trees

The OST creates a traceable line from business outcome to specific experiments. When stakeholders ask "why are we building feature X?" you can trace it back: "Because it addresses Opportunity Y, which connects to our Desired Outcome Z."

It also prevents solution bias by forcing you to explore multiple solutions per opportunity. Solutions are hypotheses until validated by experiments, not decisions.

Verify your OST has all 4 levels with connector lines flowing top-to-bottom.
Check that each Opportunity traces back to a sticky note from your journey map in Frame 2.

Tree feeling disconnected?

If your tree looks like scattered sticky notes, use Miro's connector tool (the line icon in the toolbar) to draw explicit arrows between levels. The visual hierarchy should read clearly from top to bottom.

Help me organize my OST layout.

Define North Star Metric and supporting metrics

A North Star Metric measures overall product health. Input metrics measure the levers you can pull day-to-day. This hierarchy prevents vanity metrics and keeps the team focused on what actually drives value.

Return to your Product Vision & Strategy page in Notion.
Below your product vision, add a heading called North Star Metric.
Type the following as your North Star Metric:

"Percentage of BLE connection attempts that are authenticated and authorized." Target: 99.5%+.

Add a brief rationale below the metric:

This metric captures the core value EVSecure delivers. If this number is high, users are protected. It is measurable at the BLE protocol layer, actionable by the team, and directly tied to the product's reason for existing. It moves when the product delivers value, and stalls when it does not.

Why this metric over alternatives?

"Number of blocked attacks" is a vanity metric that increases with both product success AND increased threats. "User trust score" is not directly measurable. The selected metric is input-driven and captures product value delivery without confounding factors.

Below the North Star, add a heading called Supporting Metrics (Input Metrics).
Create a table with 4 columns: Metric, Definition, Target, Why It Matters.
Add the following 5 rows:

Pairing completion rate: % of users who complete secure device pairing after starting. Target >95%. Matters because if pairing is too complex, users won't adopt.
Mean time to detect intrusion: Average seconds between unauthorized attempt and alert. Target <5 seconds. Faster detection means less risk window.
Technician session auth time: Time for technician to get authenticated access. Target <30 seconds. If too slow, technicians will bypass the system.
Fleet coverage rate: % of fleet vehicles with EVSecure active. Target >90% within 6 months. Partial coverage leaves attack surface open.
False positive rate: % of alerts that are not genuine threats. Target <2%. Too many false alerts erode trust and cause alert fatigue.

How PMs use this hierarchy

PMs own input metrics day-to-day and check the North Star weekly or monthly. Each input metric is a lever: if pairing completion drops, you investigate the onboarding UX. If false positives spike, you tune the detection algorithm.

In interviews, showing that you understand metric hierarchies demonstrates you can separate "what to measure" from "what to act on."

Verify your Notion page now has three sections: Product Vision, North Star Metric (with rationale), and Supporting Metrics table.
Switch to Miro and confirm your Opportunity Solution Tree in Frame 3 has all 4 levels connected with lines.

Not sure if your metrics are right?

Double check that each supporting metric connects to a specific user action or system behavior. If you cannot describe how the metric moves when the product works well versus poorly, it may be a vanity metric.

Help me evaluate whether my supporting metrics are actionable.

Your product strategy package is complete. You now have a vision, a traceable tree from outcome to experiments, and a metric hierarchy that keeps the team honest. Next up: a Secret Mission that positions EVSecure against the competitive landscape.

Secret mission

Build a Competitive Positioning Map

You have a solid product vision and strategy. But how do you convince leadership that EVSecure deserves investment over what already exists? Build a competitive positioning map that evaluates existing BMS security approaches and positions EVSecure's unique differentiation.

Clean Up Your Resources

This project runs entirely on free-tier accounts, so there are no ongoing costs. Decide whether to keep your artifacts for your portfolio, export them for safekeeping, or delete them entirely.

Resources you used:

Notion page: "EVSecure - PM Case Study" with 5 sub-pages (Problem Discovery & Market Context, Threat Model, User Personas, User Journey Maps, Product Vision & Strategy).
Miro board: "EVSecure - Discovery & Strategy" with 4 frames (Threat Landscape, User Journey Maps, Opportunity Solution Tree, Competitive Landscape).

Keep everything running

No action needed. Choose this if you plan to use these artifacts in interviews or extend them in the next project.

Your Notion pages persist indefinitely on the free plan with unlimited pages and blocks.
Your Miro board persists on the free plan (up to 3 editable boards total).
This is Project 1 of 3. Your next project builds on these artifacts to design features, prioritize with RICE/MoSCoW, create wireframes in Figma, and build an MVP roadmap.

Pause - I'll come back to this later

Export your work so you have offline copies, then leave the originals in place for when you return.

In Notion, click the three-dot menu on your "EVSecure - PM Case Study" page and select Export. Choose PDF format for a portable offline copy.
In Miro, open your "EVSecure - Discovery & Strategy" board, click the export icon in the top toolbar, and export as high-resolution PNG or PDF for presentations.
Your original Notion pages and Miro board remain accessible whenever you are ready to continue.

Delete - I don't want to use this again

Remove all project artifacts from your accounts. Only do this if you are certain you will not need them again.

In Notion, right-click the "EVSecure - PM Case Study" page in your sidebar and select Move to Trash. This deletes the page and all 5 sub-pages.
In Miro, open your dashboard, click the three-dot menu on the "EVSecure - Discovery & Strategy" board, and select Delete. This removes all 4 frames and their contents.

Nice Work!

You just built a complete, interview-ready problem discovery and product strategy package for EVSecure. This is exactly the kind of structured thinking that separates strong PM candidates from everyone else.

Here's what you accomplished:

Built a structured problem discovery document grounded in 4 real-world EV/BMS security incidents with a full TARA threat model (ISO/SAE 21434 Clause 15), demonstrating domain expertise and regulatory awareness.
Created 3 JTBD-based user personas validated against your threat model, then mapped current-state and future-state user journey maps identifying 4 key opportunity moments where EVSecure intervenes.
Defined a complete product strategy including an Opportunity Solution Tree, North Star Metric with 5 supporting input metrics, and a product vision using the Geoffrey Moore template.
Secret Mission: Created a competitive positioning map demonstrating EVSecure's unique market position in the top-right quadrant of high security depth and software-only retrofit.

Ready to quiz yourself?