How to ensure regular and timely shipping?
He writes the specs, input and output, then he specifies unit testing
will give unit testing to the senior coder
Elliot -specs and code review
UIUX designer -will just tell them what data he wants, and then they revise
Roger plans out with Elliot the use cases, and the activity of each use case
When product is stable, engineering team leaves it to BD
Core system, but every product pulls from it
Very rarely iterate on the product, since it's B2B
Emergency support is only 30%, 70% is on new product development
Engineering is in a separate building from BD team
Engineering team doesn't meet regularly
Coding style is standardized
Situation, Objective, Action, Aftermath
When building a B2C product, how best to conduct user interviews/surveys/experiments to discover hidden pain?
User interview is just to form the thesis
Actual behaviour on the system is validation
How should we think about technical defensibility? Or should we focus simply on delivering user results and user experience?
Portal like ours don't have technical defensibility? What's our secret sauce relative to InternSG. Very few times is our defense technical. Defenses is network. Can't think about technical defensibility when your system is not stable.
How do you measure engineers' performance? Is there performance-based compensation at QSearch?
Performance is on-time delivery on the product, and how many times we spend fixing it. He always undercalculates the timeline.
They pay market rate, without promotion.
Platform is not 1 person's responsibility, it's the architect's design.
Unit testing gotta be done before the code is started.
Breakdown by day -> we know how on/off-track they are. Ask the engineer what's their pseudo-code, and I have to debug their logic. Check in regularly, and ensure that they can do the work.
Hire an experienced engineer, because we can't be exploring new problems.
Product manager isn't critical, but someone with engineering architecture is vital. His job is very boring, come up with a blueprint to build this stable system. It's great if he is, but it's a foreman we're looking for.
How far out should we plan for our product roadmap? Enterprise is easier, but B2C is a long shot.
We need to make a hard decision on how many engineering hours is spent on supporting old product, and how many hours spent on new product dev
I need to know what system I need to deliver by a certain date, system cannot be used to do discovery
Leadership is about drawing a map, when there's no road. Imposing our imagination on opportunities, and constructing things that may or may not be needed.
What's the system gonna look like by Jan 2017?
No more hero mode. Plan for long term.
Timeline is snug but not impressive.
Elliot does code review too.
Work habits -weekly meeting, start on the dot, and agenda is in the day before, if discussions between 2 people, it skips over
Tech support tickets are on trello, if it's not on trello it doesn't exist
He'd spend his 1st month on his next startup building work habits
Most important part is knowing what has to happen by when. Engineers have to know what they are working on every day. Urgent issues go to me, we need to have a red button communication channel.
Every error message should get forwarded to someone.
If they've got a ticket they have to fix, they ought to know how long it'd take them.
How should we approach user monetization? Should we start focusing what would get consumers to pay right out of the bat?
every product is a promise
when the promise is delivered, then collect money
Should we keep a lookout for adjacent markets if we hadn't reached product-market fit? And if so, what's the optimal strategy for doing so?
They weren't looking for an adjacent market. We can theorize about serving a new market, but that's a new startup.