‍How to organise product teams

• You should have a 6-month plan and a 30-year plan — planning for the next 3 to 5 years is much harder! If you think about where the world is going to be in 30 years, then you can work backwards from there. Throw away all the assumptions you need to get there in the next 3 to 5 years and just focus on what you need to do for the next 6 months
• Coming up with overall goals for the year and prioritising them is not as effective as using an OKRs framework — this is a great way to rally your team around specific actionable things, connect their work to the org’s top strategic priorities, and be able to measure the results according to your plan. An OKR requires an objective and 2–5 key results e.g. “I will launch Gmail in September and have a million users by November” not “I will make Gmail a success”
• Often PMs are working across various internal teams (product, design, engineering, UX) which means projects can fall through the cracks — assigning a Directly Responsible Individual (DRI) to each project is a helpful way to solve for this. A DRI is not necessarily the decision-maker, but they have the authority to make sure decisions are being made fast enough as their neck is on the line if the project stalls!

What to think about before building and launching product

• Lots of problems today are often solved at a workflow level (not necessarily via patents), so when thinking about creating products it is important to find the intersection between (1) The unsolved problem, (2) An amazing user experience, and (3) A unique differentiator for your business — that’s the sweet spot!

• Once you have figured out the sweet spot, you don’t want to then build products that are just “nice to have”, but target products that are actually solving problems in differentiated ways. Using a positioning statement is helpful to test this. Geoffrey Moore’s theory is that if you can’t say the following in one sentence, it may be time to rethink what you are doing and why you are doing it…

• Data is most valuable when it helps you make decisions, not when it reinforces what you already know (think dashboards!). Before you launch a product, make sure you (1) have an expected outcome, (2) experiment and rapidly test to see if what you were going to do achieves that outcome, (3) make decisions based on that data

When considering new features

• Creating a standard formula that tests expected outcomes before making decisions helps with consistency across teams and defining priorities e.g. (1) what user segment does this affect?, (2) how many people are going to use the product?, (3) what % increase are you expecting in retention or engagement? etc.
• When testing features… ask yourself, what is the least amount of work I can do to determine whether this feature is actually going to be valuable to our users?
• Don’t care about anything but retention until your funnel is consistently retaining users — this means growth is so much more impactful later on!

Hiring — the hardest part!

At the end of the session, we discussed some key tips for hiring as we know this is a universal challenge for all founders (!)…

• When looking to find new hires, referral bonuses alone may not create the kind of behaviour you’d like — asking new hires to recommend other hires can be an effective way of unearthing great candidates that would never be on your radar
• Motivations are not uniform across each candidate — find out what drives each individual and structure your process with that in mind
• You can’t teach smarts and passion, but you can teach everything else — look for people outside of what you would typically expect
• Place weight on your own reference checks — the ecosystem is small in Australia, so reach out to mutual friends
• Make the interview a mini working session and ask the candidate to solve actual problems they would face on the job — point them to a whiteboard, “here’s a problem we are dealing with right now, can you help me work through it?”