Top 5 mistakes that I've learned from being a Product Manager in an Australian start-up
Hi there, my name is Ilya. I used to work as the Product Manager at a start-up called Instahire. As the trend of the gig economy has been spreading around Australia, it's also arrived at the temp labour hire sector. In an attempt to capitalize on it Instahire was born as a mobile app connecting Aussie businesses with hospitality and event workers at the "speed of light", in real-time. The USPs that set Instahire apart from the competition was both the instant connection and seamless payment.
Instahire's shown a number of business cases of reduced attrition rate and most importantly, saving the time and cost for small caterers and restaurants. Driven by the vision, the team behind Instahire was in sync with the passion to improve the way people work for the greater economic and social good of business and society.
During my 2+ years working in the product leadership role, I've made mistakes. Oh boy, they were many. Wishing now I'd known these earlier. Now hopefully, these will serve as a useful reminder of the pitfalls to avoid in your own software product development efforts.
Here are my top 5 mistakes to learn from:
ONE. Expectation management for stakeholders (investors).
Never underestimate the power the skill on how to speak the language of your stakeholders coming from a brick-and-mortar investment mentality, especially if they're investing into a tech startup. They will pull the plug at the most inconvenient for the product lifecycle moment - ie at the growth stage! This is a must do at the start of the development cycle and also on a regular appointment scheduled on monthly basis. Remember to be brutally honest about the result objectively backing it up with the statistics and facts, not opinions. The update should also include the forecast on the progress ahead.
TWO. Prioritisation is key when deciding on which features to build first or to build them at all.
Why would you want to risk building another version swiss-knife? There's already one that exists and I bet you have never used the entire plethora of tools that come with it. Focus instead on the repeated feedback points accumulated in the course of user interviews as the biggest pain-points. Any feasible feedback will justify going ahead to approving a new feature which may very likely scale and have a large impact on the bottom-line. At Instahire we've assumed the app UI will need a map just like Uber, showing the available workers in the area, being on standby to spring to work in a tap. In reality, what the end user needed was to be able to communicate uniform and other details in a notes section to adding clarity to each vacancy and reducing friction.
THREE. Rule #1: never underestimate the power of repeat usability tests. Rule #2: remember rule #1.
There's no such thing as "enough" testing. There’s always a chance that a user really will do that – no matter how silly it seems. In Instahire's case, it nearly cost the company 9k in unprocessed transactions that could have potentially slashed the already scrumpy budget. We're grateful to have nourished close relationships with the first time users. It paid off with the interest having their kind understanding and OK to make manual charges to compensate for the missing funds.
FOUR. Expect the unexpected in new programming.
This applies to the apps run on third-party programs and/or public API's and is shipped on a public store platform. In Instahire's case being a bootstrapped mobile app and relying on 3-d party applications, the app was prone to sudden breaks each time there's an update made by one of these programs. Yes, that means potentially your new app build will be "stuck" in approval for as long as one weeks time, busting your shipping deadline to the app stores.
FIVE. Build, test, release (or fail) fast!
Make it your mantra to release your MVP ASAP and avoid the perfectionists' trap. This applies particularly to those cases when you build a product that will meet the needs of a wide range of customers. The truth is there's no easy way to prescribe a specific solution predicting its effectiveness without actually building a prototype at the least. Instahire app was built with the features defined by the internal stakeholders and thus was more like a finished product having a number of features that simply didn't scale. A great way to make a decision on adding a feature is to ask yourself the two questions:
- How will it benefit the end user?
- How will it move the business forward?
Remember that opinions are free and everybody has one. Always try to be wise and base your answers on facts and quantitative data, or if your business in Oz then
Growth Hackers @academyxi when in growth stage of business in Australia avoid making decisions based on data but go qualitative. - Ben Fitzpatrick, WebProfits #growth #startup #growthhack #aussie pic.twitter.com/nXRf3RBM9E
— Ilya Shirshov (@Sypper) April 5, 2018
