Product strategy
Make the first release a learning tool.
An initial release should do more than demonstrate that a team can ship. It should help the organization learn whether the product is solving the right problem.
A long feature list can create the appearance of progress while delaying useful feedback. Start by naming the decision the release needs to inform. Is the user journey understandable? Does the workflow fit the way a team operates? Is the underlying assumption still true when people use the product?
Once the learning goal is clear, it becomes easier to decide what belongs in the first scope. Keep the core journey complete, make critical constraints visible, and leave lower-priority refinements for later. The goal is not to ship less for its own sake; it is to focus investment where it creates understanding.
Questions to ask
- Which user or business assumption is most important to test?
- What is the smallest complete journey that can provide useful feedback?
- Who will review the result, and what will they need to decide?
- What evidence would change the next step?
Software engineering
Modernize one boundary at a time.
Improving an established system is often a sequence of connected decisions, not a single replacement event.
Before changing a system, understand which processes depend on it, where its data comes from, and which teams rely on its current behavior. These relationships can matter as much as the code itself.
Clear boundaries make it easier to plan a useful slice of change. Choose an area where the responsibilities and dependencies can be understood, agree how the new and existing parts will interact, and define how the change can be tested and supported. A measured sequence helps teams keep learning while protecting continuity.
Questions to ask
- Which users and processes would be affected by this change?
- What does the current system own, and what does it depend on?
- How will data and behavior remain consistent during transition?
- Who will operate and maintain the updated components?
Responsible automation
Put the workflow before the model.
Automation is most useful when it is designed around a real task, clear decision ownership, and an understanding of what happens when things go wrong.
Begin with the work people do today. Identify repeated steps, the information those steps depend on, and the exceptions that require judgment. Some tasks may benefit from simpler workflow changes; others may be suitable for automation or AI assistance.
For any automated step, decide what needs human review, how uncertainty will be handled, and how people can correct errors. Keep the result observable so teams can understand whether the change is helping and where it needs adjustment.
Questions to ask
- What task is being improved, and how is it handled now?
- Is the required information available, appropriate, and reliable?
- Which decisions must remain visible or reviewable by a person?
- How will exceptions, errors, and changes be monitored?
Technology choices are strongest when they stay connected to the people, decisions, and outcomes behind the work.
Continue the conversation