1) Get leadership in a room and dont leave until you’ve thrashed out the minimum epic requirements to launch
Asking the tough slicing questions up front – before you’ve even started a design – will save a load of time. Be brutal. You can test assumptions much more cheaply than you think. Always aim to proving product-market fit.
- Don’t kick off with aspirational design which wastes time. Start with hypothesis and requirements you’re testing
- Don’t feel like you need the technical brains at this initial meeting, unless technology is a key part of your hypothesis to test. This should be a business driven meeting & no discussion of solutions
- Don’t allow any scope creep at the epic level after this meeting. If you must, it should move delivery dates – or your team will hate you and get burnt out.
2) Involve your top technical leadership immediately after epics are locked & research all possible options for build yourself – understand the strengths and drawbacks
Our company had never developed using a native framework before, preferring the flexibility and trusting the talented native developers that maintain our high growth apps. However with a simple product, there was much to be said for trusting proven framework technology and leveraging the skillset of our front end (JS) teams. In our company these developers were used to fast experimentation which made getting buy in for the project easy. We settled on React Native on day 1 which set us up to succeed. Understand the pain a decision may cause in future, but dont put too much emphasis on that – because the product might not work anyway.
3) Sell the vision & lean approach to your team in the kick off. Get mutual buy in.
This is probably the most important point. Democratise the date setting process – dont let it be driven by the senior engineers or leadership. Ensure everyone has skin in the game and benefits from hitting aggressive delivery dates. Emphasise the investment and trust given to the team. Don’t underestimate the power of a team that really hold themselves accountable – this is where passion is built. Hold yourself accountable for these dates too. Build in 20% contingency.
4) Dont underestimate all the tiny tasks needed to launch
There are so many people and departments who need to be involved in launching a complex new venture. The most valuable PM input is making sure everyone knows what is needed from them and setting them up to succeed. Organise meetings with all of them individually in the first few days. The time investment is worth it. In our case the example was:
- Community Operations – Do you have community guidelines, does your support team know how to react to various requests
- Marketing – Are your marketing plans defined & ready
- Billing – Are the IAP’s set up – have prices been agreed
- Business Intelligence – Can you measure the product properly on day1? If not you’re in trouble.
- Third parties – anyone you’re dependent on outside the company is doubly as important. If possible Make sure dates are baked into contracts and they are penalised for missing.
5) Get everyone sitting together.
Basic, but amazing how this sometimes doesn’t happen. Foster the team spirit by getting everyone physically in the same place
6) Answer the hardest questions first – build the hardest feature first.
For us, registration was the most challenging part of this product – so this was the first piece of the pie to tackle. Tackle the unknowns first and you’ll be able to react more quickly to huge project ending issues.
7) Set a team building half way through the project
Get together and get out of the office – usually this is a time of maximum pain whilst not being
the mission critical pre-launch time. The whole team will benefit from this!
8) Pre-empt Apple requirements
Apple can take extra time to verify a version 1 and quite a few new apps get rejected – which costs a lot of time. To help improve your chances I suggest:
- Dont include any payments in V1 – getting an MVP without billing will make the app more simple for them to review. If you do release with billing – make sure you follow Apple guides to a tee, subscription TnC etc – or you WILL get rejected
- Clearly explain to them how moderation and support works
- Make sure you test your app in the USA – even if your not opening USA market. Apple is in Cupertino.
- Make sure login details work!