Digital Hot Work Permit System

Executive Summary

Subcontractors were bypassing the company's hot work permit system entirely because submitting a permit (45 min) took longer than the actual hot work (20 min). As a safety manager, I tried the traditional playbook: more training, stricter enforcement, better documentation. None of it worked. The problem wasn't knowledge or attitude. The problem was incentive misalignment.

So I tried something different: What if this wasn't a compliance problem, but a system design problem?

That shift in perspective changed everything. I did some research and decided to treat it like a new product build and launch: user research, MVP validation, 6-state pilot with continuous feedback, iterative refinement, and enterprise rollout. The methodology worked because I focused on making the system so good that users would choose it voluntarily, not because they were forced to comply.

Key Metrics

From Safety Manager to Product Manager: The Journey

I came to this project as a safety manager trying to solve a compliance problem. I left it as a product manager who had discovered my calling.

The Traditional Safety Approach Had Failed

I'd tried the standard playbook:

• More training: Workers understood the process. They just avoided it because it was too slow
• Stricter enforcement: Created resentment, drove behavior underground, and didn't solve the friction problem
• Better documentation: Made binders thicker without addressing the 45-minute workflow issue
• Safety meetings: Preaching about importance didn't make the system less painful to use

The problem wasn't knowledge or attitude. It was incentive misalignment. At the field level, subcontractors get paid to complete work, not to submit paperwork. When the permit took longer than the hot work task, they were economically rational to skip it. I could either keep blaming them for being "non-compliant," or I could fix the root cause.

The Pivotal Insight: This Isn't a Compliance Problem—It's a Product Problem

That diagnostic shift changed everything. Instead of asking "Why won't workers comply?", I started asking:

• Why is this system so painful to use?
• What would make users want to submit permits voluntarily?
• How can I reduce friction without sacrificing safety and compliance?
• Most importantly: What if I treated this like a product build, not a policy initiative? That meant: user research, MVP, iterative testing, metrics-driven decisions.

I didn't know those were "product management" questions at the time. I just knew the safety hammer (policies, enforcement, training) wasn't working. So I tried a different tool.

What I Discovered

The product approach worked better for safety outcomes than traditional compliance approaches:

• Users adopted the system voluntarily because it solved their problems
• Permit volume increased 10% beyond previously captured work processes. The system was now capturing hot work that was being missed before, while still providing better visibility into actual processes
• Real-time data enabled proactive incident prevention vs. reactive investigation
• Trust-based rollout created allies instead of adversaries

More importantly, I discovered something about myself: I'm really good at this, and I really enjoy it. Building products that people actually want to use, measuring adoption, iterating based on feedback. This work energizes me in a way that policy enforcement never did.

Why This Matters Personally

I'm a builder. It's what I do, and how I identify in every other part of my life.

Safety, as noble as the work is, never scratched that itch. At the end of a project, everyone else walks away with a building standing there. They all contributed to making something. I kept people safe, protected the company from liability... but I didn't build anything. The best I could point to was numbers on a spreadsheet estimating how many incidents we probably prevented.

This project was different. I built something real, something real people use every day that improves their life. And I loved it.

That's why I'm making this transition. Not because I'm abandoning safety, but because I've found a better way to achieve safety outcomes: building products people choose to use.

Problem Discovery: Understanding the User Journey

Initial Symptom: Lack of visibility into paper process, incomplete documentation, compliance gaps

My First Instinct (Safety Manager Lens)

• Assumption: Workers don't understand importance of hot work permits, or they simply don't care
• Solution: More training, stricter enforcement
• Expected outcome: Compliance improves

What Actually Happened: Training had zero impact. Enforcement created resentment.

The Shift (Product Manager Lens)

I spent two weeks shadowing subcontractor crews on my own sites to observe actual behavior when they went through the process. What I discovered was the broken user journey:

User Workarounds I Observed

• Pattern 1: Pre-filled photocopies with outdated information (35% of submitted permits)
• Pattern 2: Complete avoidance when work duration < permit duration (estimated 20% of actual hot work)
• Pattern 3: Batch submission at end of day for work already completed (22% of permits)

Breakthrough: What Happens When Users Actually Use the System

During the pilot, a subcontractor foreman gave me feedback that crystallized everything I was trying to do. He initially viewed the digital permit system as additional steps—more work on top of an already demanding day. But after a few weeks of using it, his perspective shifted. He realized the system wasn't adding work; it was freeing up his time. Instead of filling out paperwork, he could focus on what he was actually good at: setting up his crew for the day, supervising quality, catching safety issues before they became problems.

This insight shaped how I marketed the solution to the rest of the company. It wasn't "compliance made easier." It was "your supervisors get their time back." That reframing changed adoption from a compliance initiative into a productivity play.

Through the discovery process, it quickly became clear that the solution wasn't better enforcement. It was building a better product.

User Needs vs. System Reality

Build vs. Buy Decision

The Evaluation

Before building anything, I evaluated vendor solutions:

Why I Built It Instead

None of the vendor solutions addressed the core problem: making permits easier than not doing permits. Plus:

• We already had JotForm licenses ($7K/year for entire department)
• I could build an MVP in two weeks vs. 18-month dev cycle
• No-code meant I could iterate based on real user feedback daily
• Full control over UX for both English and Spanish speakers

Solution Development: Discovery → MVP → Pilot → Iteration → Enterprise

MVP Design Principles (Week 1-2)

Based on user research, I designed for:

1. Mobile-first: QR code access, works in 2 minutes on any phone at any point of work
2. Remove friction: Auto-populate location, date, time. Only ask what the user uniquely knows.
3. Bilingual by default: Full Spanish translation, not an afterthought
4. Instant value: Auto-email copy to submitter, super, and safety team immediately
5. Make success visible: Live Power BI dashboard showing who's compliant

The Pilot (6 Sites, 3 Months)

I picked 6 sites that represented our range of operations including excavation and concrete work, steel erection, wood framing and finish work:

• 2 large sites (500+ workers)
• 2 mid-size mixed sites (100-150 workers)
• 2 small sites (50-100 workers)

Pilot success criteria: 50% adoption rate with zero enforcement OR users report system is easier than paper

What I Learned During Pilot

Initial feedback was brutal (first 2 weeks):

• "Too many questions" (original form: 40 questions)
• "My phone died, now I can't work?" (edge case backups)
• "I submitted it, now what?" (unclear next steps)

Rapid iterations (weeks 2-6):

Breakthrough moment (Week 5): Superintendent at Florida site said, "This is actually easier than our old way. I can see all active permits across the whole building from my office." Adoption at that site hit 90% within two weeks - with zero reminders from safety team.

Feedback Discipline: 20+ Iterations Driven by User Needs

The pilot wasn't just about testing adoption—it was about systematic feedback loops. Over the course of the pilot and rollout, I implemented over 20 pieces of feedback directly from users. Some were feature requests; others were workflow improvements.

The most common feedback theme: field teams don't check email. They check text messages. The request was straightforward: "Can we get notifications via text instead of email?" The insight behind it was deeper: I was optimizing for an office workflow, not a field workflow. Field teams are mobile, constantly switching between tasks, and email is a low-priority channel.

I implemented text notifications because the feedback wasn't about preference—it was about understanding how the actual users work. That's the difference between building features and building products that people choose to use.

Pilot Results: Voluntary Adoption Without Enforcement

Enterprise Rollout: Phased Adoption Based on Real-World Constraints

After pilot success, leadership approved enterprise rollout. Rather than mandate immediate 100% adoption across all sites, I structured the rollout to align with business realities: new jobs come online throughout the year. This meant phased adoption by quarter:

This phased approach demonstrates realistic thinking: adoption doesn't happen overnight, especially in construction. By aligning rollout with new project starts, we set users up for success rather than forcing adoption on existing workflows.

Rollout strategy:

1. Champion identification: Found one super at each site who "got it" - equipped them to evangelize
2. QR code blitz: Laminated QR codes at every trailer whiteboard, provided them to subcontractors performing regular hot work to stage in work areas
3. Make data visible: Weekly email showing top 5 sites by compliance rate (gamification without saying it)
4. Respond fast: Committed to fixing any reported issue within 48 hours
5. No enforcement: Deliberately chose not to mandate. Made success visible instead.

Technical Implementation

Architecture

Built entirely on no-code platforms leveraging existing company licenses:

Key Technical Features I Built

• Smart defaults: Auto-populate site, date, time based on QR code location and submission time
• Conditional logic: Branching paths based on work type, locations or conditions (fire watch, roof work, thermal image camera use, etc.) - only show questions relevant to the specific work type
• Bilingual switching: Users toggle language at top of form; all conditional logic works in both languages
• Photo evidence: Mandated photo upload of work area to allow for virtual compliance checks
• Automated notifications:
  • Submitter: Instant email receipt with permit details
  • Safety Team: Real-time notification of new permit request for approval
  • Superintendents: Daily digest of all permits
• Power BI integration: Live dashboard showing compliance by site, super, subcontractor, and date range
• Email-to-print innovation: Automated physical permit printing to trailer printers within 30 seconds of approval (discovered existing printer email-to-print capability)

What I Personally Built

I configured every aspect of this system:

• All JotForm logic including conditional branching paths based on work type
• Power Automate flows for notifications, data transformation, and Power BI sync
• Power BI dashboard with 7 different compliance and adoption KPI views
• Bilingual form translation (with help from Spanish-speaking staff)
• QR code generation and laminated signage placement strategy across 35+ sites
• Email-to-print automation logic and testing
• Written documentation and training guide to have an artifact that lived on and acted as a single source of truth for the entire process

Business Impact & ROI

Building for Multiple Stakeholders: User, Buyer, and Validator

One insight I discovered: the system didn't just serve the users (subcontractors and supervisors). It served the organization's stakeholders—specifically, anyone responsible for compliance and risk management.

During an OSHA walk on one of my pilot sites, I showed the compliance officer the digital permit system. Her reaction crystallized why this product has value beyond time savings: "I had never seen anything like this before, and I thought it was exactly the direction the industry needed to be heading in order to combine digitization with better information workflows and overall safer practices."

That comment revealed something important: this wasn't just a permitting system. It was a modern compliance infrastructure that demonstrated due diligence. Since then, the system has been shown at approximately 25 insurance audits and walks annually, and is regularly discussed during OSHA inspections (roughly 1-5 times per year when hot work is relevant).

Every time we have an audit walk, compliance professionals ask for a copy of the most recent hot work permit. We used to scramble through paper records. Now, we pull it in 30 seconds from a searchable database. That difference—between "we can't find it" and "here it is"—is not just a compliance win. It's a risk management win that compounds across every audit touchpoint.

Detailed ROI Calculation Methodology

Time Savings Basis (Validated During 6-Month Trial)

Before the digital system:

• Field time per permit: ~45 minutes (travel to trailer, fill form, wait for approval, photocopy)
• Admin time per permit: ~20 minutes (safety manager review, filing, tracking, routing)

After the digital system:

• Field time per permit: ~10 minutes (scan QR, fill mobile form, instant confirmation)
• Admin time per permit: ~1 minute (automated review notification, zero filing/tracking)

Net savings per permit:

• Field users: 35 minutes saved (78% reduction)
• Admin/safety: 19 minutes saved (95% reduction)

Conservative Year 1 ROI (Phased Rollout)

Based on realistic phased adoption (63% average Year 1):

Year 2+ ROI at Full Deployment

At 100% mature deployment (4,200 permits/year at 35 sites):

Why These Numbers Are Defensible

1. Time measurements are validated: Tracked 50+ permit submissions during pilot, measured completion times
2. Volume is based on actual data: 4,200 permits/year from 8 months of real submission logs (extrapolated conservatively)
3. Trial data supports scaling: Tested across 6 diverse site types with 700-800 permits/month
4. Labor rates are conservative: Used $40/hr field rate and $80/hr admin rate (many field supers earn $45-65/hr)
5. Phased adoption is realistic: Year 1 model assumes 63% average (not immediate 100%)

Unmeasured Value

The ROI calculation doesn't include:

• Incident prevention: Zero hot work incidents vs. historical 2-3/year (each incident: $50K-$200K+ in costs)
• Insurance value: Demonstrable compliance reduces Experience Modification Rate (EMR)
• Audit readiness: Can pull any permit in 30 seconds during OSHA inspection (25 audit walks/year)
• Subcontractor relationships: Subs actively prefer working at our sites because permits are easy
• Safety culture: Visible dashboard created healthy competition between sites
• Compliance confidence: OSHA officer assessment that this represents "the direction the industry needs to be heading"

Leadership Approach: Building Influence Without Authority

The Coordination Challenge

I had zero direct reports but needed buy-in from:

• 15-person safety department (who preferred paper permits)
• 35+ superintendents (who didn't report to me)
• 100+ subcontractors (completely outside org chart)
• IT org (who saw this as "shadow IT")

How I Built Adoption Without Authority

1. Made it voluntary, then made success visible

• Never mandated use during pilot (deliberately chose adoption over compliance)
• Weekly email showing top 5 sites by compliance rate
• Superintendents started asking "How did Dallas get to 90%?"

2. Found champions, equipped them to evangelize

• Identified one super per region who "got it" early
• Gave them talking points: "It's faster than paper, I can track it from my truck"
• Let them convince their peers (more credible than safety guy telling them)

3. Responded to feedback within 24 hours

• Every complaint got a "Fixed" email the next day
• Users started testing me: "Can you add [feature]?" I'd add it overnight.
• Built trust that their input actually mattered

4. Made it work for subcontractors (the hardest users)

• Subs don't care about our compliance problems
• Made QR codes so easy that submitting took less time than arguing about it
• Instant email receipt gave them proof of compliance (they started using this to push back on other GCs)

5. Positioned IT as partners, not obstacles

• Briefed IT leadership before pilot: "I'm testing this with existing licenses. If it works, I'll need your help to scale it."
• Shared pilot data showing ROI before asking for enterprise support
• When IT offered to "rebuild it properly," I negotiated: Keep the UX, add their security requirements

Post-Rollout: Ownership & Sustainability

Ongoing Performance Tracking

The system continues to track key metrics on a weekly basis:

• Adoption rates by site and superintendent
• Abandonment rates (current: 24%, down from initial 38%)
• Compliance completion times (tracking performance consistency across sites)
• System uptime and performance (response times, submission success rates)
• User feedback and feature requests

Sustainability Without Me

This is critical: the system runs independently of my daily involvement.

I intentionally architected it this way:

• Decentralized administration: Each region has a trained super who handles user support and troubleshooting
• IT ownership: IT team owns the Power Automate workflows and infrastructure
• Self-service dashboards: Anyone can view live metrics without asking me
• Documented runbooks: Every process documented for IT to maintain independently
• Exception handling: Automated alerts when something breaks, not dependent on me discovering issues

Post-launch support model:

• I provide monthly reviews of adoption and abandonment metrics
• IT handles technical maintenance and platform updates
• Regional supers handle user training and on-site support
• No daily creator involvement required

Future Product Pipeline

This hot work permit system validated a broader insight: construction safety has massive product-market fit potential.

What comes next in the platform vision:

1. Equipment Inspection Permits - Digital system for tracking equipment certifications and inspection status
2. Confined Space Entry - Complete workflow for planning, training, and monitoring
3. Toolbox Talks - Mobile-first training delivery and completion tracking
4. Fire Watch Assignments - Real-time scheduling and accountability

The hot work permit is the MVP of a larger safety operations platform. Each module reinforces adoption of the others by solving adjacent problems with the same no-code approach.

Why This Matters for My Career Transition

The Honest Story

I didn't wake up one day and decide to become a product manager. I was a safety manager trying to keep people from getting hurt, and traditional safety tools (policies, training, enforcement) weren't working.

I always thought about means and methods to change the fundamental system but had never acted on them. This time I decided enough was enough. So I tried something different: treating safety problems like product problems. And it worked better.

Higher adoption. Better data. Fewer incidents. More trust. Sustainable long-term.

That's when I realized: I'm not a safety manager who happens to be technical. I'm a product manager who happens to understand construction safety deeply.

What Makes This Transition Authentic

Most PM candidates come from:

• Software/tech backgrounds (no construction domain expertise)
• Construction operations (no product development skills)

I bring both:

• 5 years living construction jobsite realities (I know why offline mode matters, why mobile-first is non-negotiable, why Spanish localization isn't optional)
• Proven product management skills (discovery, MVP, pilot, metrics-driven iteration, voluntary adoption, $196K-$310K validated ROI)

The Unique Value Proposition

Most construction tech fails because it's built by people who've never worn steel-toed boots. They optimize for demos, not workflows. They don't understand that:

• Field teams need 99.9% uptime (not 95%)
• Mobile-first isn't a feature, it's a requirement
• "Quick training" means under 10 minutes, not an hour
• Physical/digital hybrid is reality (you can't go fully paperless)
• Bilingual isn't "nice to have" - it's table stakes

I learned these lessons by living them. That's not something you get from market research.

Why Product Management

Because the product approach works better for safety outcomes than traditional safety management. I can prevent more incidents by building great products than by enforcing policies. And that's what I want to do full-time.

Technologies & Skills

Technical Stack

• No-code platforms: JotForm (form builder), Power Automate (workflow orchestration)
• Analytics: Power BI (custom dashboards), JotForm Analytics (conversion funnels)
• Integration: REST APIs, webhook triggers, email-to-print protocols
• Documentation: Markdown, Notion, Zoom Whiteboard (collaborative workflow mapping), Mermaid (workflow diagrams)
• AI-assisted workflows: Large language models for rapid prototyping (generating conditional logic scenarios), documentation drafting (user manual translations), and workflow visualization (converting process descriptions to diagrams)

Product Management Skills Demonstrated

• User research and ethnographic observation (shadowing field workers)
• Build vs. buy analysis with TCO calculations
• MVP scoping and ruthless feature prioritization
• Pilot program design with representative user diversity
• Metrics-driven iteration (abandonment analysis, time-to-complete tracking)
• Systematic feedback loops (20+ improvements based on user input)
• Cross-platform integration architecture
• Mobile-first UX design for field conditions
• Bilingual product localization
• Multi-stakeholder product thinking (User/Buyer/Validator framework)
• Change management without organizational authority
• Technical documentation for non-technical audiences
• Stakeholder management (field crews to C-suite)

Construction Domain Expertise

• Jobsite workflows and operational constraints
• Subcontractor economics and incentive structures
• GC compliance obligations and insurance requirements
• Field conditions (weather, connectivity, mobile device usage)
• Safety/regulatory requirements (OSHA, insurance, state codes)
• Union vs. non-union labor dynamics
• Multilingual workforce communication

What This Case Study Demonstrates

• Authentic career pivot story (safety → product discovered through necessity)
• Product management skills proven in real environment ($196K Year 1, $310K at maturity)
• Construction domain expertise that can't be faked (5 years on jobsites)
• User-centric iteration (38% → 24% abandonment, 37% improvement)
• Multi-stakeholder product thinking (User/Buyer/Validator framework)
• Phased rollout strategy (realistic vs. aspirational adoption curves)
• Leadership through influence (voluntary adoption without mandates)
• Technical execution (personally built all components)
• Sustainable design (system runs without creator)
• Systematic feedback discipline (20+ iterations based on user needs)

Most importantly: It shows someone who discovered their calling by solving real problems, not someone trying to jump into tech because it's trendy.