Product & Engineering
- pair programming
- we treat Financial vs Technical products as separate things. Technical is an implementation of the Financial product.
- Enable multiple clear and parallel work streams. Personally, I like each contributor to have at least primary and secondary work stream so that if they need to wait for feedback on one task, they can do work on the secondary work stream in the meantime. Basically, you don’t want blockers to immediately turn your async work into sync work for 2 or more people.
- Encourage frequent status updates on projects as the work happens, and automate these updates if possible. Err on the side of over-communicating.
- Avoid DMs unless you really need an immediate response. The ephemeral nature of a DM means it demands attention at the risk of being completely forgotten if ignored.
- Keep communication tied directly to the ticket, issue, or doc created for the related task. If you have questions or feedback, leave them as comments as closely connected to the right context as possible.
- Ensure comms requiring a response are always easy seen, searchable, and the right people get notified. If people feel think their feedback will be lost, they start defaulting back to DMs and other high-escalation comms.
- Establish an “SLA” on what an expected response time should be for feedback and questions on a project. Async should typically allow for a response “within x hours” for normal issues. The number of hours may depend on how many time zones your team is working across.
- Make sure someone in a lead role is taking responsibility for ensuring work meets that SLA for response times. If things slip, bump them back to the surface.
Service Design
References
- https://www.reforge.com/the-road-to-100m
- https://bootcamp.uxdesign.cc/the-intersection-of-fit-market-product-channel-model-14921b3a1a13
What is service design?
= Multi-dimensional product thinking
Don't just design each and every step of your users journey whether or not you are part of each step. Also design users thoughts and actions between each step of your service.
- Breaks in flow to give user time for decision making
- Rhythm and tempo of steps in sequence
- https://twitter.com/abouelatta_ali/status/1594707038642249728
while its important for each step and task to be well-designed, it doesnt mean that these things are services. The only person that decides what the service is, is the person who has the goal they need to achieve — and thats your userIts your job to orchestrate all of the pieces of this service in as as seamless a journey as possbile, even if you dont provide the whole service yourself
Understanding context of your user and where they are coming to your from is critical. When we try to solve one small part of a problem with a slice of a service we arent as effective as possible. The cost of providing our service might be cheaper (likely not if your service isnt designed well) and that cost is being born somewhere else by the user or another service provider.
Modern SaaS departments are much more co-dependent than independent. For example, we now understand that churn isn’t a customer success problem, it’s an organizational problem — from product, to sales and marketing, to support, and even operations. Reducing the gaps means seeing, evangelizing, and optimizing for the opportunities across  team boundaries — https://siliconyall.com/2019/02/saas-ceo-role/
