Top 10 Free tips for new starters in Product or Project

My top 10 FREE tips to anyone starting or looking to start a career as a Business Analyst, Project Manager or Product Manager on the back of 2 decades working in these areas

1. Delivering value and outcomes matter more than anything else – especially the journey or process to get there. Your users DON’T CARE!! If the tasks that you’re doing are not adding value (value being more users, less churn, more revenue/profit, less expense etc.) then challenge it. Don’t be afraid to ask WHY. HiPPo requests are inevitable, but make sure you record them (see point 8). So many processes creep into daily life which actually inhibit the ability to add value. Box ticking, meetings, forms. Cut out as much as possible to maximise getting the value you’re building into the hands that will use it and pay for it.
2. People are the critical success factors, not the software. Invest time in understanding the needs and problems of your users. Build relationships with your stakeholders. The person using the product is more important than the manager paying for it. Learn the personalities of your colleagues, how they respond. Research your user behaviour. Tools that provide analytics are vital in seeing how people are responding to your product.
3. Know your data. Where it comes from, who owns it, what shape is it (do you have to clean/reformat it before it can be used, and can it be changed at source without you being informed), how often does it update are just some questions to get answers to. This in the foundation of anything you will build. Fail to do this and do it well – the consequences will be serious.
4. Communication – Ignore at your peril. The style and cadence will differ for each stakeholder group and things like RACI matrices are handy to at least document the intended approach. Making sure the right people know what’s going on at the right time removes any unpleasant surprises. Keeping people in the loop with enough information they need is invaluable. Don’t waste peoples time with meetings that can be done by email. If you need a meeting, give a reason, an agenda, and expected outcomes / actions following if appropriate. If you want an answer from someone, make it clear the timescales and the expected response from them.
5. Expect the unexpected. Sometimes referred to as the known unknowns, there will always be things you are aware of, but don’t know the exact detail of such that you can’t design or code for. Making a list of these plus any assumptions or mitigation plans will always minimise the impact if and when they happen. Being able to react calmly, provide assurances to the appropriate people and after resolved document what happened and what was done to resolve is invaluable references to keep.
6. KISS. Keep it simple silly. I’ve seen products and projects delivered via many different methods. I personally don’t like Scrum. I think it’s a process designed to help engineering teams more than delivering products. The less admin work you can have in your processes the better. On one occasion where I had freedom to operate my way, we got rid of refining, points, sprints and just used a simple Kanban board. The stories were bulleted lists of how a feature should work, lots of diagrams and wireframes plus casual conversations saw entire systems delivered from the ground up in a few months to a high quality.
7. A plan B is never a failure. When it looked like a deadline was not going to be met for a feature launch, my proposal for a backup plan was met with a “that is not acceptable” response from my manager. The attitude of planning a backup means your not focused on the primary being successful is just plain wrong. It links closely to point 5. Having a backup plan is just good practice. It’s not a sign of failure or lack of ambition for A to succeed.
8. Document everything enough. Agile is famed for its “low document” approach on paper but in reality it I’ve seen a wide variety of implementations and sometimes HUGE amounts of documentation consuming more time than it took to do the job itself. Things you should always document:

• • Feature requests – Who asked and when. Why is it needed. Value it adds. Risk of not doing. Urgency
  • Change requests – as above.
  • Diagrams, sketches, UML models are invaluable. Annotate them with JIRA/ADO ticket ID’s so you know what’s been done/covered.
  • Have all your notes/documents to hand structured in a way you can easily access.

9. It can be a lonely world. You are often responsible, and accountable but rarely do you have authority. Agile concepts suggest that the team holds responsibility for what it does and how it does it, but in reality this inevitably falls at the feet of the PM, especially when it goes wrong. Creating an environment of trust, respect, work hard/play hard, collaboration and humility has worked for me to engage a team and bring them on a journey with me that has delivered great products in record time. Trying to appease everyone pleases no-one – especially yourself.
10. Look after yourself. Your mental & physical health is more important than the job. Creating boundaries & routines is essential to keep your health in tip-top condition allowing you to perform at your best. A BA, PM or PO role can often be like a conductor at an orchestra, a plate spinning routine, a cat herder or a lion tamer. It can be an AWESOME job – when everything comes together and you can celebrate the successes as a team.