You know what your customers want, and you understand how your customers use your services but the process to design and execute any Product strategy against its objectives, adding new features or service levels must always consider the final mile, this thing needs to be built and will your customers actually use it.
Be ready to iterate, gather feedback and go again. (or not)
I have been designing tech solutions for 7 years and have become fascinated by the opportunities technology offers, the ways it improves and benefits a users ways of working and even their lives.
Yes, you will encounter friction along the way, whether that is due to the technology, budget or diminishing appetite from users but the challenge is always one you should relish.
So your goal is to give your users and the target audience something new or a different take on existing capabilities, it should improve and equally change the way they work and interact with the product for the better. But just solving the problem on paper and designing an optimal user experience is just the start, the service needs to be built and users have to login which comes with its own learning.
It can take time to build successful products.
Statistically, 7/10 will fail. It’s therefore imperative to;
There is often uncertainty in product development.
A wise man once told me that you can cheat your way in to the garden of achievement but your journey and what you get out of it is directly related to what you put in.
To be successful is not easy, the more you want it, the more energy you apply to reaching your goals the more resistance you will encounter and opposing forces can push your goals further away. It will often become harder the more you want to achieve so plan it right from the start, expect resistance along the way and remember that you do not need to reach the garden of achievement at the first go.
If you turn up to the door early, chances are, you will have cheated or cut corners and the last thing you want is to give your internal and external customers a substandard service.
Failing to plan you must expect to fail.
Understanding where and how your product positions is critical to ensure that you are going to deliver a service which will be adopted by your target market, but if the solution or platform is both new to your current or potential users how far do you take it, you do not want to overwhelm users with too much choice from the beginning.
So should you build a feature rich offering, a perfect user experience and optimal technology platform from the start?
Naturally you want the best for any of the products you manage and at all times! but do you actually need the best from the outset, after-all it's a journey? So aiming for that golden ticket is great but often all you need or may ultimately get is far from the vision.
My latest product release was a mobile app for our web based enterprise service, why? the platform was never optimised for mobile which is, more than ever, a defining factor for most global marketing organisations seeking to employ new technology solutions across their business. Mobile platforms ultimately create agility and build deeper engagement across teams.
As an established, feature rich platform embracing new technology and importantly mobile tech, is not something you can take lightly. It costs and is also niche, mobile apps have their own frameworks due to the many different devices and code frameworks in the supply chain.
So do you build one app for all, supported on Apple and Google Android or do you build natively to each?
Remember the costs, any decision must consider the impact of;
It all adds up to the total investment required to build and to achieve the vision, planning and making those trade-offs early will place you in a stronger position to attract new investment and commitment from your business to pursue the paths you seek to create, so know your KPI’s.
If you live and breathe mobile in your product function you will also know that there are specialty developers who build for iOS and Android respectively. There is Material and Swift code frameworks which allow you build the most effective and efficient version of the app both catering to the native device and user experience of each OS.
In recent years new players have also emerged in the app space, Facebook, the most notable, who prompted the React code base as a rival to Angular. As an open source standard, React has not only been adopted it has often been favoured over Angular and with its foundation in Facebook, a mobile first platform, it has super charged React. This heritage is why it has been adapted by many dev shops who have since built their own sub frameworks to enable speed of delivery by building generic mobile app products for their customers.
Making a concession on the code base, opting for an open source sub-framework like React, should not be taken lightly. We opted for NativBase which was made to increase our speed to market but also, due to the lack of mobile development experience in-house, it enabled our team to learn fast. The team are proficient senior frontend React practitioners and were more than capable to take on this new challenge.
Of course there are other aspects to this which can impact you when using these "sub-frameworks" such as support, documentation and design limitations, but there are also benefits. Since our resources could not scale to bring in experienced mobile developers we saw some quick wins taking this approach, offering us a route in to mobile where we could test, learn/fail fast.
We designed our app with simplicity in mind, providing users with a view of our ordering service, whilst this was light in terms of feature capabilities this is powerful to our users who need to stay informed of their TV orders. Ordering is how our customers send their advertising copy to TV.
Ultimately if the mobile app is a success we acknowledged and accepted that that we may need to rebuild in Native and commit to to an invest in to mobile to included developers and deeper infrastructure.
Know your KPI’s
Tracking the usage of your APP and using these insights to drive the next wave of investment and development will allow you to learn fast and fail fast.
Your have defined the product MVP and are poised to validate your hypothesis, your product MVP is based on what you are trying to answer from your customers before you can iterate again, adapt and enhance or pull back.
Measuring the performance and tracking success is key for any product owner to make the right decisions to move forward and also concessions so building an MVP is with your customer in mind and not because of time or cost, if the customer sees no value the initial version then measurement will bias towards negative, which is equally valuable but can often mean a reset of expectations and can actually increase costs.
Each question is pertinent in driving forwards with your mobile product, so know how to track, monitor and engage.
Taking a holistic approach to consolidate reporting in to one service or implementing a third party is my preferred approach, and is wholly beneficial for Enterprise platforms. Consolidating in to your in-house data warehouse or embedding a third party app will save you time and cost when reconciling data, for me, opting for a third party service (AWS Pinpoint) allowed us track all app use regardless-of device. This is an holistic approach and offered a standardised way for us to report, often informing me in real-time versus Apple or Google respectively.
Both Apple and Google offer similar but not identical or even generic ways to monitor app downloads and usage and users are also more aware than ever about sharing their personal device data and will often disable device monitoring/data sharing to apps from their Apple or Android device respectively.
Our platform customer are already paying for their users to access the service. This affords us to keep all personal user data obfuscated from our data warehouse. Since we already track via the web platform and built the app on top our existing core services we simply required a header extension to include mobile activity, this allows us to differentiate mobile app traffic from the web. The data we gather from the Platform offers insights via our UUID, from this we can understand how the platform is used and adopted without ever requiring personal information about the individual.
Planning the product launch was considered, we designed the app to focus on users who engage with our Delivery module.
Our objective, target “high volume” activity users. We took this approach as we know who is an active user of our platform and who are using Delivery and its key features included in the companion app. This meant that we could in principle go after users with a higher propensity to engage, download and use the app on day 1 and be the early adopters.
Linking this usage data from pinpoint would track engagement levels and repeat use factors. This would lead to targeted follow up messages to ask why you are not using the app or what would bring you back - followed by questions about what feature would matter most to inform the roadmap.
Critical to all of this is continuous release, making small adjustments as you go. Delivering new features should always be on your agenda, but importantly you cannot appear stagnant.
The most popular apps on the app stores often see updates as frequently as weekly while other release cycles may happen once or twice a month. Driving adoption and downloads as well as managing your release cadence will show your users/early adopters that you are very much alive and kicking.
Our app is designed as a refined companion app, offering a view of one module. We enable Brands and agencies to deliver content to almost every TV broadcaster in the world, pretty powerful right? and providing a view of an ad is in its delivery cycle is important, especially when advertisers have sizable budgets behind each campaign.
Success at this early stage is making sure our app does the basics but ensures that it can also say it in every language, we are an international company delivery TV ads to each corner of the globe.
The global launch on day one is English, after our second month we will target the support of at least 20 languages.
What might seem like a basic app can be used and understood by thousands, and this simple approach further enables us to extend our communication and target each marketing message in their native tongue.
Engage and drive home the roadmap
Building advocacy across your customers does not stop at the users who have already downloaded the app or those who fit the mosaic of users who could and should download the app.
If you believe in your product and you already know your customers have an appetite for mobile then leverage their interest, this is a prime opportunity to drive awareness to everyone.
Targeting your paying customers to build your roadmap will mean that you can build deeper connections and allow you to make customer focused decisions. Why develop features for the sake if it, just because you have a feature rich platform does not mean you need all of the features on the mobile. You want drive downloads and build your market presence by offering meaningful services you customers want or need.
This approach will also allow you to build your business case for further investment. But remember, you should not be afraid to fail, if this product offers low or reduced revenue opportunities, interest in developing the product or adding purposeful features is not high on your users interest furthermore there are no indirect benefits that will increase sales by having a mobile app then do not be afraid to pull back. Cutting your losses will save you money and allow to focus on more imperative revenue drivers.
Trade-offs are often hard, but can also be a shrewd way to ensure success and speed to market, fail fast so you can adapt and evolve quickly.