Procurify: Culture, People & Org Insights

Fred, Lindsie, and Neil all went out of their way to put you at ease. Fred explicitly said the conversation was about getting to know you. Lindsie and Neil's session was described as "lovely" and "forgiving." Even Riley, who was more structured, connected on parenting. This suggests warmth is cultural, not just individual personality.

Lindsie's stated value is "radical candour." Neil values candour explicitly. Riley pushed back when answers were vague rather than letting you slide. Neil pushed back on Andrea's tech debt position with the financial loan analogy. They test for intellectual honesty, not agreeableness.

Lindsie: "guardrail governance without overburdening with process." Neil: "decisions made by those closest to the information." The CARES value of Simplicity is described as "focus, clarity, streamlining to cut through complexity." They want structure that serves outcomes, not structure for its own sake. This is a meaningful distinction — they've likely been burned by over-process before.

Neil and Lindsie openly described the CX-to-engineering triage problem (Intercom/Jira noise). They shared that Productboard didn't work. They told you the AI committee is ad hoc and not functioning well. They described the R&D-to-GTM communication gap as a real pain point. This level of openness in an interview is a strong cultural signal — they're not hiding problems to sell you the role.

Neil echoed Andrea's "change hearts before minds" framing. He explicitly values "allowing people to feel comfortable to collaborate, experiment, and empower themselves." The AI transition is being navigated with awareness of mixed feelings across the org. Leadership is being respectful about it, not steamrolling.

The PM team has clear domain separation: Riley (procurement flow), Fred (AP automation), Tony (integrations/platform). Each interviewer had a distinct style and brought different evaluation lenses. They're building a team of specialists who coordinate, not generalists who overlap.

Multiple instances during their joint session where they weren't fully synchronized. Not conflict — more like two people who've been solving the same problems from different angles (design vs. engineering) and are still converging. They were both visibly pleased about wins they'd achieved together (common dashboard, shared terminology). Funny moment: when Andrea mentioned her psych/polisci background and human-centered approach to change management, Lindsie excitedly said "isn't that what you also majored in?" to Neil — but Neil actually majored in philosophy. Mostly awkward, a little funny. Shows comfort with each other (a mix-up like that is only low-stakes if the relationship is solid) but also that they don't know each other's histories as deeply as their working rapport might suggest.

Both brought up SDLC multiple times. They've clearly put a lot of thought into workflows, rituals, cycles, and feedback loops. Neil got particularly animated here — this is the space where energy and pain converge. The person who fills this role will inherit their thinking and be expected to operationalize it.

Both Riley and Fred stuck to their ATS tracker questions. Riley was particularly diligent about filling it out properly. This suggests a structured, documented hiring process — which often reflects how the company approaches other processes. Decisions likely need paper trails.

Fred mentioned 5 PMs with overlaps in what's being built. Known domains: Riley (procurement journey first half), Fred (AP automation second half), Tony (platform integrations). Two PMs unidentified. The overlaps Fred mentioned suggest coordination challenges — exactly what this role would address.

The role is explicitly the combination of what Lindsie and Neil have each been partially covering. This is important: you'd serve two leaders with different priorities (Design vs. Engineering) but aligned values. The relationship between them appears strong and collaborative — they interviewed together, finished each other's context, and didn't compete for airtime.

5+ years, rose through every level. Manages the broadest scope (Web, Mobile, Platform, DevSecOps, Data Engineering). References to Karpathy tweets and org structure reviews suggest he's actively involved in strategic decisions, not just execution. If there's a political center of gravity in R&D, it's Neil.

Both joined in late 2025. They're establishing their domains in parallel. This means the PM org is still forming its identity and working norms. Good news: less entrenched politics, more openness to new ways of working. Risk: things may shift quickly as they settle in.

Neil mentioned top-down admin rules for Jira statuses (one project per engineering team). This suggests engineering ops has some centralized control, which may mean less flexibility for experimentation in tooling but more consistency across teams.

Neil said this explicitly. R&D town halls went from monthly to quarterly and are going back to monthly — a sign they tried to reduce communication overhead and it didn't work. Company town halls are quarterly. The bridge between what R&D builds and what GTM teams sell/support is broken enough that it's a primary responsibility of this new role.

Neil shared a quick flowchart during the session. Andrea noticed that visually, all the lines were straight — none of them closed back into loops. Conceptually, this maps to a broader pattern: people are collaborative and working together, but there likely aren't enough closed loops, follow-ups, and checkpoints to confirm thinking or validate decisions. The R&D-GTM gap, the CX triage problem, the town hall cadence changes — all symptoms of information flowing forward but not being verified on arrival. If this hypothesis holds, closing loops is the single highest-leverage thing this role can do.

Across all four rounds, nobody described outright dysfunction or adversarial teams. People talk as though they work collaboratively. The gap isn't willingness — it's infrastructure. Missing: feedback loops, checkpoints, shared visibility. The common dashboard was a recent win precisely because this connective tissue didn't exist before.

5.5 years of institutional context, broad scope, excited about SDLC reform, transparent about pain points, going deep on rabbit holes. He's carrying a lot and is ready to hand significant pieces off. If there's one relationship to invest in early, it's this one.

Goal: add meaningful AI throughout the user journey to remove toil. They want to market the product as "agentic" soon. AI applies to both product (user-facing) and internal workflows. This is an ambitious timeline — roughly 12 months remain.

Fred's domain: actively layering AI (auto-filling invoices, reducing time-on-task). Tony's domain: no active AI, architecture work lays the foundation. This uneven adoption is normal but means your role would need to understand and bridge these different stages of readiness.

Tony's integration work is explicitly to support mid-market growth. Fred described the tension between mid-market simplicity and enterprise complexity. Procurify appears to be moving upmarket from SMB — which changes everything from pricing to support to product complexity expectations.

Lindsie and Neil are simplifying the product development lifecycle and "protecting for AI-driven changes." Roles are starting to collapse with AI. This is a live transformation, not a future plan — and it's one of the core responsibilities of this role.

Because Procurify owns many of its own integrations, Tony sees a potential opportunity to expose that functionality to the broader ecosystem and create agentic workflows. Still early-stage thinking, but an interesting strategic direction — moving from integration consumer to integration platform.

Tony mentioned 1–2 solution architects and maybe one engineer for the professional services function. For a company pushing into mid-market with long-tail ERP integrations, this is notably small. Either the plan is to grow it, or Procurify is betting on product-led integrations over services-led customization. Worth clarifying — this has implications for how Tony's domain scales.

Jira (one project per engineering team, centralized admin rules for statuses). Two-week sprint cycles, standard scrum.

Intercom (CX tickets) → Jira. Current pain point: too many tickets routed to engineering that are actually usability/expected behavior, not bugs. CX pre-filtering is insufficient.

Notion (doc store), Figma/FigJam (design), Miro (cross-functional collaboration), Slack.

FullStory (session replay/analytics), Gong (call intelligence), Reforge (product insights — replaced Productboard).

Salesforce (CRM, source of truth for account data), Vitally (customer success).

Claude Code (recently adopted), Cursor (considering). These are developer tools — suggests engineering leadership is actively experimenting with AI for internal productivity.

Just established a common dashboard/view for all teams to see shared information. This was new enough to mention as a win, which tells you how fragmented visibility was before.

Serving both Lindsie (Design) and Neil (Engineering) means potential for conflicting priorities. Their relationship appears strong now, but what happens when they disagree? Understand the escalation path and who has final call.

The role description is vast: customer voice, tooling, AI committee, PDLC, R&D-GTM bridge, change management. This is at least two full-time roles. What gets prioritized in the first 90 days? What explicitly does NOT fall on this role?

18-month AI-native roadmap started ~4 months ago. 12 months remain. Mixed feelings across the org. PDLC being reworked simultaneously. Roles collapsing. This is a lot of change happening fast. Is the org actually ready, or is leadership ahead of the org's capacity to absorb?

Fred and Tony are both ~5-6 months in. Working norms, coordination patterns, and domain boundaries are still being established. You'd be joining a team that's still figuring itself out — which is opportunity but also ambiguity.

Neil described this as a real pain point. It's the kind of problem that's easy to inherit and hard to solve structurally. Understand whether this lands on your plate day one or if there's existing ownership.

1–2 solution architects for the entire professional services function. If mid-market customers expect customization (and they will, especially around ERP integrations), this team is undersized. Clarify: is the plan to grow services, or is the product expected to absorb that complexity?