OPERATING DESIGN · PRODUCT JUDGMENT · AI-ASSISTED WORKFLOWS
I learned execution in transactions, then became the first dedicated M&A hire at a Blackstone-backed company and built the operating process around the work.
Since then, I have applied the same habit to AI-assisted workflows and products I build and test myself: make the problem concrete, build a first version, use it, and change what reality proves wrong.
DELIVERY UNDER PRESSURE
Royal Paper's $180M+ sale to Sofidel America ran through a Chapter 11 Section 363 court-supervised process.
The deadlines were fixed. The dependencies were real.
As a deal team analyst, I supported the process across financial and operating analysis, transaction materials, buyer outreach, diligence, process management, and execution, and assumed primary execution responsibility after a mid-process staffing change on the deal team.
The work required a constant view of what had to happen next, who owned it, which workstream was waiting on which piece of information, and what needed escalation before it became a blocker.
A process like that does not stay clean because the plan was good on day one. New information keeps arriving. Priorities move. People become constrained. Dependencies change.
The job is to keep the critical path visible anyway.View public transaction ↗
BUILDING AND PRODUCT JUDGMENT
The same pattern shows up in my independent product work: make the assumptions explicit, build enough to challenge them, and keep a visible distinction between what exists and what still needs evidence.
Northstar did not start as an app idea.
I was managing a job search, product work, learning, and several competing commitments at once. I began using AI conversationally as a personal operating layer: plan the day, force priority tradeoffs, adapt when reality changed, close the day against what actually happened, and synthesize the week before planning the next one.
Over time, repeated use exposed rules that were useful enough to formalize.
What should remain a conversation, what deserves a dedicated interface, and which of these behaviors are useful beyond the way I personally work?
Dogfooding came first. The interface came later.
People can say what matters to them, but their actual allocation of time and attention may tell a different story. Northstar explores whether planning, execution evidence, reflection, and adaptation can become one useful feedback loop.
Not every important task can be P0. P0 must materially change the day or week, P1 is important, and P2 is maintenance or flexible. The useful behavior is accepting the tradeoff.
P0 · P1 · P2A plan is credible only when it competes for actual time. Fixed commitments stay fixed, flexible work can move, and the system replans from now when the day changes.
Capacity · Dependencies · ReplanningCompletion is based on what actually happened. Daily review captures completed work, deviations, blockers, actual time, and decisions so the next plan starts from evidence.
Plan vs actual · EvidenceA weekly recap should not repeat seven daily summaries. It should decide what continues, what stops, what changes, and what deserves another week.
Retrospective · AdaptationI have used AI throughout the live workflow to structure priorities, challenge overloaded plans, replan around changing constraints, synthesize daily evidence, identify patterns across weekly reviews, and carry forward useful operating context.
The hard part is not adding a chat window. It is deciding what becomes persistent context, what is observation versus inference, what the system may suggest, what requires confirmation, what is not evidence, and where human judgment remains final.
AI should help people live their lives, not live their lives for them.The conversational workflow is where I have been actively using AI. The interface prototype specifies how those behaviors could be represented in software. Its model connection is intentionally disabled.
Northstar can support universal planning problems such as priority, capacity, sequencing, tradeoffs, overload, and replanning. That does not make it an authority in every life domain.
For uncertain choices, form a working hypothesis, run small real-world experiments, observe interest, effort, energy, feedback, and behavior, then update the hypothesis. Direction should evolve from evidence in action.
The initial research plan became too broad. I stopped treating research completeness as progress and reset the sequence to:
Strategy → Focused Research → Prototype → Real Usage → BuildThe rule became simple: research a question when the answer could change a product decision. The daily planning layer is still a hypothesis, not a sacred feature.
The current version is deliberately shaped around how I work. Customer interviews are separating three things:
Real recurring user problem · Personal preference · What existing tools already solve well enoughThey are testing generalizability, not proving demand, willingness to pay, retention, or product-market fit.
Priority and time are one decision, not two. P0, P1, and P2 sit next to the schedule that must actually absorb them. The goal is a realistic allocation decision under limited capacity.
Prioritization · Capacity · Sequencing · Time allocation
A review should change the next plan, not just score the last one. The weekly view compares intent with execution, surfaces recurring patterns, and turns them into Continue, Stop, and Start decisions.
Plan vs actual · Retrospective · Pattern detection · Adaptation
Northstar makes operating rules explicit and editable rather than hiding them inside a generic assistant. It distinguishes persistent rules, observed evidence, AI behavior, and final user judgment.
Persistent context · AI constraints · Evidence · User control
Plan → Act → Observe → Learn → Replan
A behavior can be useful to me every day without proving that a standalone product needs to own the entire daily-planning stack.
Calendars, task managers, planning tools, and generic AI already solve substantial parts of the workflow. Integration alone is not differentiation.
Using the system myself exposed product mechanics worth testing. It does not prove that other people have the same problem or want the same solution.
Tend is an AI-assisted product for busy professionals who already know and care about their partner, but do not always have the planning bandwidth to turn that knowledge into a thoughtful gift, date, or small action.
Instead of asking the user to reconstruct their partner in every prompt, Tend explores whether structured partner memory can make those decisions more useful and more executable.
I took the concept from problem framing through structured research, product definition, high-fidelity interaction design, and an MVP build.
Home opens the Tend interaction. Partner Memory supplies its context.
Home is intentionally lightweight: enough context to act without turning the relationship into another dashboard to manage.
It keeps the next useful action visible and provides the entry point into the core Tend interaction through the green Tend button.
The core interaction uses remembered partner context to support AI-assisted date planning, gift discovery, and small thoughtful actions.
The product is not trying to help someone care more. It is designed to reduce the planning and decision load between knowing your partner and actually doing something thoughtful with what you know.
This is the core interaction represented in the current MVP / product build. It does not imply a live production AI backend.
Partner Memory organizes preferences, experiences, emotional needs, important dates, and other user-provided context so the user does not have to reconstruct their partner in every interaction.
Persistence itself is a product decision: what may be remembered, what may be inferred, what should require confirmation, and what should not become persistent memory at all.
Gift ideas, restaurant recommendations, and conversational brainstorming alone are not meaningful differentiation.
Reusable Partner Memory, native gift / plan objects, and partner-specific context became the core differentiation hypothesis.
AI can interpret intent, match context, rank options, and explain recommendations. Deterministic systems or trusted external sources should own prices, inventory, opening hours, routes, and URLs.
WHAT THE WORK DOES NOT PROVE
Beachhead segment · Differentiation versus generic AI · Willingness to pay · RetentionEXPERIENCE
First dedicated M&A hire at a Blackstone-backed healthcare services company. Built and operated the process behind screening, diligence, executive reporting, and integration planning.
Generalist transaction execution across analysis, transaction materials, buyer processes, diligence, and coordination.
Consumer sell-side M&A across live processes from marketing and buyer outreach through diligence, management presentations, and closing.
Client-facing consumer banking while completing Accounting and Finance degrees.
UNIVERSITY OF ROCHESTER
UNIVERSITY OF HOUSTON
CREDENTIALS
WORKING STYLE
A model, dashboard, workflow, meeting, or feature earns its place only if it changes a decision or a behavior.
Anyone inside the work should be able to tell what is moving, what is blocked, who owns the next action, and which decision is waiting on it.
I would rather expose a first version to criticism than spend longer perfecting assumptions in the abstract.
When people work around a process, misunderstand it, or quietly stop using it, that is information about the design.
Models, research, and AI can all produce confident-looking output. Assumptions should stay visible, and unsupported conclusions should stay out of the decision.
HOW I THINK ABOUT AI
GET IN TOUCH
I build products and AI-assisted workflows around problems I want to understand better, from noticing the problem and researching it through to getting something working. I am most useful where the problem is still being defined.