I liked this article from Scott Belsky that talks about the importance of the first 15 seconds of interaction with new users. According to him, the keys are;
- Demonstrate the benefit of engaging clear even before users engage with the product,
- Make using your product “share-worthy” so user look good when they talk about you,
- Deliver immediate benefit to reward the engagement to keep them hooked.
Check out the whole article here:
How do you build a product that engages a user quickly enough to engage them over time?
A few weeks ago, I posted on the trade-offs between native, hybrid and responsive approaches to mobile development. A recent article by Roi Kraus in Techcrunch delves deeper into the subject. His conclusions are:
- Choose hybrid which is faster and cheaper to execute if you don’t need native functionality,
- Go native if you need to use extensive communication, access lots of data or use many of the phone’s onboard components (like graphics, GPS, etc.).
- If you go native focus on one platform first to avoid managing multiple developments simultaneously,
- Focus on user expectations rather than business needs in choosing which way to go.
See the whole article here: From Native To Hybrid App Development And Back
Retargeting has become one of the most popular tools for recruiting users to a new service. The idea is simple; potential users who visit one of your online properties but don’t immediately sign up are targeted with ads that aimed at recruiting them. The theory goes that by retargeting previous visitors, you are going to reach people predisposed to signing up, slashing recruitment costs.
A recent article “Past Behavior Does Not Determine Future Purchases” questions the premises upon which retargeting logic is based; namely that past online behavior is an indicator of future behavior. Indeed, a user may be on a shared device, his browsing history may be driven by an objective other than purchase or he may have already made his choice. The key is to know your recruitment cycle; generally speaking, each product has a well defined recruitment cycle with length and steps varying with the nature of the service and complexity of decision.
The basics are that the retargeting audiences must be as precise as possible (separating signups from non-signed up visitors for example). Then you can begin to create messaging that fits each step of the recruitment cycle; basic product benefits for new visitors, offers of deeper information during the decision making process and perhaps even a competitive switch offer to those who have not signed up yet, just before the end of the evaluation period.
See the original article: “Past Behavior Does Not Determine Future Purchases“
Recently, I wrote a post about the perils of customisation and feature requests. Just saw this cool article on @Invisionapp that points out that many times, customisation requests are really caused by poor UX. The customer simply can’t figure out how to do what he needs to do easily, even if your software actually could allow it.
Its worth taking the time to understand the underlying motivation behind these feature requests to see if its not just a problem with the way your service makes some features available.
See the original article: Integrating feature requests without destroying your product
A number of startups I work with ask me about whether it still makes more sense to invest in a full-blown mobile app rather than focusing on a responsive website or a hybrid app.
- A responsive website is one that presents a specific layout for each width of screen (often called a “break-point”). The huge benefit of the responsive appraoch is that people can access your service without installing anything and you don’t have to develop different versions for each operating system.
- An application, often called a “native app”, runs software optimised for the device which optimises performance and reduces what needs to be downloaded from the net. Apps have access to device functionality that is unavailable to responsive websites (eg. location) and they are usually feel snappier. You do however have to develop for each operating system which can mean for a lot of work since there are four major mobile operating systems.
- A hybrid app is a mix of web and application. Some functions run locally on the phone, notably things that are not accessible from the web, while others are pulled from the net. A key benefit of this approach is that you can share a common development for web and hybrid app, deployment across multiple devices is much simpler and it is easy to update functionality without updating the app. The downside of this approach is that user experience is not as good as the “native” experience and performance can be slower due to the reliance on the network.
With the above in mind, deciding on what to do depends a lot on whether the primary usage of your service is to be on mobile devices or not and whether success depends on the sophistication of the user experience. Here are some questions you can ask yourself;
- Demographics: What is age and mobile usage of your target group?
- Installation: How would users find out about an app to download it? Are they more likely to look at a website?
- Updates: How often will you need to change the way the app works?
- UX: How much does the success of your service depend on the UX itself?
- Functionality: Do you need to acces functions on the terminal that require an app?
For example a game that requires fast response-time and really slick user interface will probably opt for native development. An information site which does not need to use the phones local features may be better off going with a responsive approach. A professional app that needs to track location, stores information locally and has frequent functionality changes to meet evolving business needs but which does not need a sophisticated user experience may go for a hybrid app. The following table may help;
|Responsive||Native App||Hybrid App|
|Update||Transparent||App install||Usually transparent|
|Access to local features||No||Yes||Yes|
|Multiple OS support||Yes||An ap per OS||Much can be reused|
How many times has a customer told you they would love to buy your product if only it did this tiny little thing that you don’t have on your roadmap? The natural instinct is to make a deal with the customer for a long-term comittment if you deliver the missing functionality. The client gets what he wants, you get a new customer and everyone is happy, right?
The problem with this is that customisation is one of the most disruptive things that can happen to a lean startup with a small team trying to achive great things in record time. Engineers have to stop what they are doing, get their heads around a totally new request and see how they can pull it off.
Even pricing custom work can be tricky as the pricing has to include development and testing time as well as all the complexity of validating the specification and the opportunity cost of having your scarce engineering resources working on something non-strategic. Things can get worse if there are interdependencies between the customer’s infrastrucutre and your system as any changes on the customer’s side leads to more work for your team. Most startups I have worked for dramatically underestimate the cost of these customisations and usually end up loosing money on them.
To my mind, the best approach is to set up a separate team that focusses soley on customisation if this can enable substantial sales. This way you can more easily understand the impacts and costs of customisation while leaving your core technology teams focussed on making your product even more awesome.
A new startup often gets their first real break when a *Big Customer* finaly realises how awesome the product is. Benefits for the startup are immediate; cash, credibility, better understanding of how the product meets a real customers need and a great boost to the team’s motivation.
But its not all good news. Large customers know how much leverage they have on a small company and often use it to exctract special conditions as part of the deal, often promising even more business when the solution is adoped more broadly. Also, these larger customers have very specific requirements and internal policies that don’t give the the latitude to be flexible. This means that if they are not careful, the startup can slide into a situation where everything they do revolves around a single customer who asks them to modify their product, spend lots of time with in-house and generally do stuff the management team had never planned to do. It can be very defocussing if internal operations are not structured to handle it.
Don’t get me wrong, big customers are great if you can get them, you just have to make sure they don’t end up running your company.
In a recent article in Tec Crunch, Tai Ziv riased the question about whether it was better to incentivise downloads or rely on “natural” downloads to build the audience.
This is a real challeng for most entreprenneurs and a question well worth considering. Organic customers usually cost less to recruit are are genuienly interested in your product. However, the speed at which you recruit will depend on how you can get the word out. For example, if you are a major airline with an app that helps your customers wich you can promote on your booking site and on each e-mail you send, then organic may well be the way to go. However, if you are a startup with no name recognition and no customer base, you probably need to look at some sort of incentivised acquisition strategy.
Another factor worth considering is that there is a huge benefit to getting early downloads both because it can help your position in app stores and because most apps work better if there is a larger user base forming a community. When in doubt, budget generously for download incentives and user acquisition.
See original article:
What’s Better? Incentivized Or Non-Incentivized App-Install Campaigns