choosing the platforms

With multiple mobile platforms to choose to support, taking a product vision and working out the best approach to implementing your Minimum Viable Product ready for roll-out to early stage adopters can be a daunting prospect. Do you target web first and mobile later, or do you target Apple devices first, Android next? Do you use a cross-platform technology to target all mobile platforms at once, or do you invest the money to implement on iOS, Android and web all up front? Other key questions include how much investment is needed to design the UX at the early stages? How do I get value for money from the UX services supplier? Being first to market is key in today's mobile world, how quickly can we get our product to early stage adopters on as many platforms as possible? What web services and external software services do we need to integrate with, and what are the licensing requirements? Bringing the concept to reality is a complex task.

choosing the mash-up

Many concepts emerging today are offering benefits derived from integrating different services pulled from a variety of sources, sometimes called 'mashups'. This brings with it a need to coordinate with multiple software services vendors and to perform software integration activities. Sidstan offers a track record in successful software integration and product delivery, leading to investor-ready minimum viable product, management of roadmap and early stage adopter deployment.

monetising mobile

The reduced screen resolutions associated with mobile apps and the commercial requirements placed on app vendors by app stores taking a product or service mobile can involve rethinking the purchase process and revenue strategy. From the concept definition stage to product realisation these factors need to be considered. 

going global

The app works in English, but what will it look like in Simplified Chinese or Korean? What do we need to consider for deploying the product or service in Hong Kong? These type of questions, if not being asked now, are likely to be asked at some point in the product lifetime. Factors such as internationalisation and scalability need to be factored in from the start. No investor wants to be faced with a complete product rewrite 1 year into the product life-cycle. If the foundations are right first time round then we ensure that the back-end and the front-end apps serve a longer life-span. Simply, make sure the foundations are right from the outset to save the pain later on.

managing the build

Do we need to hire developers, do we outsource the product development or can we manage the development using freelance coders? With 25 years of experience in managing new product development, from enterprise user profiling engines, IPTV, mobile and SmartTV entertainment products, and always first to market, we can work with you to plan the realisation of the product vision, architecting the early implementation and delivering the product to those all too important early adopters. 

how to quantify the take-up

You'll quickly want to know how often, how long and from where your apps are being used. There are many analytics tools to help. We can help choose the right tools and the right data points to be collected to perform the data mining later.

scrum, sprints and iterations

Does Agile mean we do things quicker? When will we be "finished"? Actually, will we ever be finished? When do we test? Do we do UAT at the end or as we go? Have we got the courage to give the team space to breathe? These are some of the uncertainties that come with moving to Agile processes. In our experience Agile can mean doing things quickly, but it's all relative and it depends on where you are starting from. You might already be agile but haven't acknowledged it. For one, don't let the Agile Manifesto rule you. It's there to serve your business, not for you to serve it. Do what feels right, but for sure, as a team, take time to stop regularly, reflect, and frequently think about ways to do things better next time.

addressing scalability

There are many facets to software scalability. Scaling a product means a lot more than determining whether the web traffic throughput can be handled. Scalability involves criteria such as can the required language and cultural localisation be catered for? If the product involves online purchasing are the processes in place to cope with the different paths of transaction handling and at the forecasted volumes? Can the UI cope with larger data sets, for example consider how many items are going to be in a drop down list, is pagination of lists in place, have you left space for languages that tend to have more characters in words? Scalability can go downwards too. Downwards scalability can be in terms of system resources. A good example being websites that now have to consider the constrained environment posed by mobile screens and operating systems. Scalability is an exciting challenge, one that needs thought about from product inception and acted upon at relevant intervals as the product vision is realised. 

balancing the short term and the strategic initiatives

A large customer base, with product deployments and sales activities happening on a global scale and across many cultures, can mean balancing short turnaround requirements needed to keep up with customer needs with the strategic initiatives and company vision for the future of the product-set. This is something that can be easier managed once a software development team reaches critical mass, but for a small company and team this can be a significant challenge. Agile methodologies, short iterations and continuous integration do help. Applying simple lightweight processes and short delivery iterations are key. Further, choosing the right tools can make delivery of both sales cycle requirements and company vision move forward at a predictable and manageable pace. Many tools, some free, have recently emerged to help, such as the Kanban board mobile app Trello. More sophisticated tools such as Pivotal Tracker include pace-monitoring, completion prediction and progress modelling. The main thing to remember as always is the tool is there to help, and choosing the right tools for the right job makes requirements balancing achievable. After all, a development team being in high demand is a good thing, it's how the team is empowered that counts.