Have you ever had a mindblowing business idea? We bet you have. Almost everyone has been there at some point. In our line of work, we also encounter more or less interesting ideas and thoughts almost every day. They come out of nowhere and can disappear in much the same way. So how do you figure out which ones are viable? What makes the difference between success and failure? What pitfalls should you watch out for? And how do you go about creating a working product or service from scratch?

We know a little something about that, so we decided to share our knowledge with you in this e-book. We have every confidence that you will find inspiration here as well as answers to your questions about business ideas and their life cycle.

How do ideas originate? One's own experience or an unmet need and the effort to come up with a better solution to one's own problem is often the driving force. You probably will not find out right away whether the idea is functional and has business potential. However, the following steps can help you a lot.

“The first thing we recommend doing is using Lean Canvas. People often immediately focus on execution as opposed to solving a problem.” Jan Minárik

You have an idea. Now what? Examine it thoroughly. Divide it into smaller parts, look at them closely and from different angles. Focus on the cause of the problem, not just dealing with its consequences. A number of tools can help to quickly and easily guide you to the questions you need to answer before you move forward. For example, Value Proposition Canvas and the follow-up Lean Canvas.

We like Lean Canvas because it is an easy-to-understand guide that walks you through the next steps, such as defining the problem users have, its possible solution (your product or service) or key metrics. This detailed (but not complex) business plan will help you organize your ideas, possibilities and goals.

The classic SWOT analysis is another important tool.This helps you analyze the strengths and weaknesses of you and your team. You figure out what skills are key to a successful implementation of your idea, what you can do yourself and what you need help with. Thanks to this analysis, you can put together a capable and effective team.

“Today, many people are fixated on the execution of solutions. But they are often not able to name the problem these solutions are meant to solve. Because, in fact, they are not solving any problem. They are consumed by this vision of executing an idea in a specific way. But that's not how you create products. It is necessary to think about the fact that users (your target group) have a problem that they need to deal with. Alternatively, there are other solutions on the market, but they are not suitable for various reasons.” Jan Minárik

Many people come up with a solution straight away without verifying that there even is a problem that requires their solution. Which is often the reason for failure. Therefore, it's a good idea to start by defining the problem you want your business to tackle. You don't have to come up with a specific solution right away.

“Case in point: one experienced client came to us with a problem and wanted us to come up with a solution. The product was created gradually and validated regularly--a total of 28 versions were created before we succeeded.” Jan Minárik

“You need to be getting feedback from clients from the very beginning. The product team’s mission is to find a way to get it as quickly and cheaply as possible. The vision of the final product often limits our creativity in interacting with users in the beginning. We rarely realize that we can add value for users even without developing a complex system.  Paper and pencil or an Excel spreadsheet will do just fine. We can't do it for hundreds of users, but 5-10 users is quite often doable. Actual user interaction with your idea is a great source of information for your product team. At the same time, you can easily compare the expected value with reality. That's why we--together with our clients--always look for ways to get feedback on their idea without having to start developing right away.” Martin Srb

Know what problem your idea solves and what it offers to the users.

Lean Canvas can help with this. You will be able to organize your thoughts and plan the next steps.

Look before you leap. Leave the execution for later. Organize your ideas and thoughts first.

Did you enjoy the preview of our upcoming e-book on product development?

Don’t miss this practical guide through all four stages of development (shape vision & ideas, validation, build, scale) based on our own experience. Give us your email address, and we will let you know as soon as it is ready.

Life and death of ideas: An idea is born, what's next?

There is a problem plaguing the startup world: the need to invest tens or even hundreds of thousands of euros in the development of a product that no one uses in the end. At Applifting, we decided to solve this problem once and for all using the traditional methods of our ancestors. Our product team’s newest member is familiar with tarot cards, healing crystals, dice, and is even able to work with a crystal ball.

At Applifting, we have been building a top team of product and UX designers for two years now, assisting our clients in identifying gaps in their products and dealing with them before we build the solution. We help our customers to save money they can utilize for other activities, whether it’s the development of other functionalities, financing health care in Africa or purchasing covid tests and respirators as per current government regulations.

Our team is very efficient and can usually validate the product within two to four weeks. But what if you need to guarantee the success of your product immediately, and you just can't wait? No problem, that is what we are here for!

“What if you need to guarantee the success of your product immediately, and you just can't wait?”

We hired a fortune teller as part of our product team, and the change was almost instant. We managed to reduce the validation time from a few days or weeks to hours or sometimes even tens of minutes. And we'd like to introduce you to the tools we use to do that.

Probably the most handy weapon in our armory. We usually organize an introductory all-day workshop with the customer at the beginning of the project during which we try to get a feel for the product and client needs. However, when choosing the right medium, a crystal ball provides you with a contactless way to obtain all the information, which is not only economical but also hygienically safe. And that’s all the rage in the pandemic age, isn’t it.

We managed to buy several sets of various dice for cheap from a group of our colleagues (who recently moved their Dungeons & Dragons sessions online). They can be used to rigorously estimate which areas of the Value Proposition Canvas are the most important for a particular product. In addition, if the customer requires a cost estimate before defining the product, we can now give them an educated guess that is based on more than just the experience of our developers.

Numerology is one of the most convincing methods our seer uses. Assorted sets of numbers (often using competition statistics, user estimates, and demographic data) allow him to predict the often unexpected surprises that lie in store for the soon-to-be product. This is based not only on his colleagues’ experience with the creation of business plans, but also on the book Numerology for Dummies. And for the more complicated projects, he always keeps The Numerology Guidebook close at hand.

Medicinal herbs and other natural products

According to current historical research, our prehistoric ancestors already knew the beneficial effects of medicinal herbs and mushrooms on creativity. However, in keeping with the rules of our Applifter's codex, we do not condone substance abuse--our seer may therefore use only the means prescribed by his doctor (to treat arthritis, of course) to stimulate his creativity.

Saving the best for last, the use of tarot cards when validating startup ideas proved to be such a success that we decided to show our hand and reveal to you how we do it. With the help of the following instructions (download here) and a deck of tarot cards, you too can become the parent of a new successful startup.

Unfortunately, some studies show that divination is not one hundred percent reliable, and therefore we recommend comparing the results with modern methods of startup validation. Not sure where to start? No worries! Get in touch with us, and we will be happy to help you. For free.

Make sure your startup is a success: classic validation methods

Last time, we introduced you to various technologies and their pros and cons. Now let's have a look at the timing side of things.

We now know a little more about what choices we have. But take a simple example: a landline and a mobile phone. What problem do both devices solve? Instant connection of people over distance. This basic use case will always be met, that much we can rely on. However, mobile phones are the result of the development and increasing demands of the users. It also costs more  than a fixed line, both in terms of acquisition and operation. And it's the same with mobile solutions. It all depends on which stage you and your product are in. 

Do you have a mindblowing idea you need to validate? Do you have a solution to a problem and a bunch of unsupported assumptions? Why spend money on something you don't know will work? It is worth thinking about what I need to do to ensure traction for as little money as possible and to mitigate as many risks associated with my solution as possible. In this article, we write about a limited selection of solutions for the mobile platform. But keep in mind that there are simpler solutions than a web application. To get started, try building a landing page, sending out a newsletter, or directly asking your potential users to evaluate it.

Did you succeed in approaching early adopters? Have you tested your hypotheses? Are people interested in your solution for their problem? It's time to start raising funds, to reach out to investors and move on to the next level. Ask for funding right from the start! At this point, we can move on to the next stage in mobile solutions based on our key factors. Service monetization is key, as is the ability to turn users into paying customers.

Your first stable paying users! Good job, you are starting to generate revenue. Let's ensure that our solution is even better and craft the perfect experience for our users. Maybe it's time to modify our design, expand the functionalities. We need to ask our users and maintain a feedback loop because if we lose touch with them, it is easy to start heading in the wrong direction.

Are we able to secure ROI? Perfect, it means that we can finally calm down a bit and focus on further development of our service. If this has not been necessary so far, it may be time to finally move onto native development. Users do not feel safe using our PWA solution, and now is the right time to do something about it. We need to shift our business to the next level.

These are the four basic product phases which we will focus on in the following paragraphs. You will learn what steps you can take given the stage you are at and what your key factors are.

Were you looking forward to getting to the end of the article to find out what to do? This might disappoint you a bit, but there is no one specific approach to mobile platforms and digital innovation. Just like no one will tell you how to manage your startup. The reason is plain, it's simply because there are too many variables to consider. You can draw parallels here with infinite games. All we're trying to do is to mitigate the risks to keep everything running. Therefore, we are not talking about finite games in which the goal is to win.

Despite everything mentioned above, I will try to guide you a little. We discussed the key decisive factors for the selection of solutions, we also dealt with the individual phases of the product. So how is it all connected? I will try to answer that using the table below. It will provide you with tips for different mobile solutions depending on key factors and the stage your product is in.

None of the solutions are all-encompassing, each of them is suitable for a specific phase and a specific key factor. The problem comes when there are more of these key factors, or when decision making takes on another dimension. Subsequently, we always try to minimize the risks because it is no longer easy to choose which way to go.

Different solutions are suitable for different product phases, so it is necessary to accept that when you’re moving from one solution to another, you might need to start the development process again. That is--from a programming point of view--to start from the ground up. But do not worry, this is not always bad news. Situations like this are the perfect opportunity to reflect seriously on what brings core business value to our solution and transfer only that, as well as what we’ve sufficiently validated with our customers, to the new one. Product work does not end with the MVP, quality product work is a never-ending cycle of ideation, sketching, validation and development. A product without feedback from customers (and paying customers) is doomed.

When all is said and done, don't go looking for a cookbook for mobile (or any other) digital product development. This is a process that is far more complicated. Brainstorm, define, share, validate, make informed decisions, and ultimately take a little risk. 

Did you miss our webinar? No worries, we have a recording for you.

Anything else you’d like to know? Or just interested in discussing your application and how we can help you out with it? Drop me a line at jan.hauser@applifting.io.

When, Why, and How to Go Mobile: When is the right time for native development?

In the first article of the series, I briefly introduced mobile app development technologies. Let's look at them in more detail now. Which factors are key for the mobile platform? How do the individual approaches we outlined last time stand up to scrutiny? Just to jog your memory, we’re comparing SPA/PWA, Native Wrapper and hybrid (Flutter) and native technologies. 

We take into account the basic factors our customers usually focus on and specifically ask about. These include the price (first and foremost), security, performance/optimization, access to device functions (bluetooth, NFC, camera, security storage, ...) and last but not least, platform coverage (Web, Android, iOS). As you go from SPA to native development, you will notice an increase in most factors including price. In some places, however, the differences are so subtle that the issue is not so clear-cut. 

However, all the parameters must be viewed in the context of your digital product, that is to say which stage your product is in, primarily. But we’ll explore that in the next paragraph.

Price is definitely one of the key factors as founders make their decisions primarily with regard to ROI optimization. This is absolutely understandable, whether we are talking about self-funding or external investment. The price for the development of mobile applications increases with the level of functional requirements and size of the development team.

The cheapest solution is to build a website or an SPA. This gives you a solid foundation, a bargain at twice the price. In addition, if you decide to go the SPA route, you will also have the backend ready for the future mobile app.

If we take a web application or an SPA and enrich it with service workers and a few other functionalities, we make the move to PWA. Sure, it will cost a little extra, but it gets us closer to native-like experience. Though a little pricier than with PWAs, the Native Wrapper is one alternative to consider.

The transition to hybrid technology means writing the whole application from scratch. There is not much to reuse. Here comes one key decision in terms of price: do we embark on the path of hybrid or native development? Remember that native development will always be about 1.5 times more expensive than its hybrid counterpart.

You can read on the Internet that SPAs are worse off in terms of security than server-rendered web applications. This is because most of the source code is on the client side. However, if you follow all the established rules for cookies, authorization, and authentication, you are OK. In addition, when talking in the context of mobile applications, the client-side source code argument is relatively odd. And with PWAs, it's the same story.

Moving on to Native Wrapper, the use of limited code obfuscation or access to security storage devices is beyond the scope here. That gives us slightly better security.

On the other hand, faced with developing an app with special security demands, such as banking apps or just generally those working with sensitive user data, the decision between hybrid and native development comes again. We can use native code obfuscation or access to secure storage hardware in both cases. Thus, there is a significant increase in the possibilities of application security and backend communication. Again, you need to follow the authentication and authorization standards mentioned above. Hybrid technologies have slightly more limited options than native technologies, but it depends on how low-level we need to get concerning security. Last but not least, there is the possibility of using a native workaround in a hybrid codebase (which Flutter allows). This means writing specific parts of a hybrid application in native code, separately for each platform.

Honestly, this is a rather vague request that almost everyone makes. But what does a sexy app mean? First of all, quality UX/UI design. If you're going to experiment, do it with UI, but stick to familiar UX patterns depending on the platform.

Using all the proposed technologies allows us to customize the interface according to the platform. And therefore we always do it. The same pattern and better performance can be applied here, from SPAs to native applications. When animation and other heavy performance components come into play, Flutter or native development is the right choice. It will always work best on mobile devices. One such example is Spotify and PWA Spotify Lite.

Let's utilize all the features and sensors phones have

We should first investigate camera access. You can approach it with any solution, the only question is what it will look like and how deep you will get.

So it's worth thinking about how customized your approach will be. In addition, in the case of a web browser or a PWA, you may run into problems due to support on iOS devices. Some customization enabled on Android may not work automatically for iOS. You need to be careful and keep this in mind.

The further we move from a SPA to native development, the more low-level we get. The same applies to other features, such as NFC, Bluetooth, accelerometer or gyroscope.

Communication with other applications within the mobile ecosystem represents another problem with PWA. Case in point, accessing contacts on the device is not possible at the moment, but there is light at the end of the tunnel. This functionality should be released at least for Android anytime soon.

All approaches are equal here. Whether you decide to go with mobile-optimized web applications or PWAs, you will reach the main mobile platforms globally in both cases. With PWAs, you can even "install" the app and facilitate a relatively good user experience. When I say "install", I mean to download the app to your phone and add a launcher for faster access. Keep in mind that PWA support on iOS is still limited and not all features are available to the same degree as on Android. But you will definitely recall the lite versions of Facebook, Twitter or Spotify. They are all PWAs. At the same time, you don't have to worry about uploading your apps to Google Play and AppStore. But this is a fairly contradictory factor because just as it can make distribution easier for you due to no store fees, it can make it harder for you because you don't use a global distribution channel.

All these implementations allow you to publish the application separately on both platforms. In that respect, it’s a tie. But what is worth mentioning is the ability to choose only one platform and make it your market strategy. Do you want to validate your idea through a limited group of users? Is native the only option for you? Try starting out with one platform and extend the solution to another platform the moment you manage to validate the concept through a limited group of people. Did Clubhouse decide to go exclusively with iOS because of the "more affluent" users that make up a big portion of Apple customers? Or was it that limiting the number of users makes it easier to ensure and verify the stability of the product and the ecosystem? You can think about your product in a similar way.

Now you know the pros and cons of each technology, and all that's left is the right timing. We will dig into this together in the last article in our series on mobile development.

Anything else you’d like to know? Or just interested in discussing your application and how we can help you out with it? Drop me a line at jan.hauser@applifting.io. 

When, Why, and How to Go Mobile: The advantages and disadvantages of different approaches

“Hello, I need to create a mobile app. I want it to run on all platforms and reach as many potential customers as possible. At the same time, I need to quickly turn free users into paying customers. I want the app to be swift and sexy. And yeah, I have very limited resources, and I need it yesterday. Can you give me a price estimate? ”

Sound familiar? Have you ever had to deal with anything like this? And which side were you on? At Applifting, we act as the supplier. And it happens a bit too often.

Our task is to outline the possibilities, explain the pros and cons, board a helicopter and look at the whole problem from a bird's eye view, in the broader context of the product itself. And because we want to look at it in detail, we prepared a series of three articles for you. So make yourself a cup of coffee, get comfortable.

Let's take it from the top. If we talk about a mobile application, you probably imagine an app on either Google Play, AppStore, or AppGallery in China. But it's not that simple. You can achieve the desired effect with either web-based solutions, e.g. Single Page Application (SPA) or Progressive Web Application (PWA), a Native Wrapper (Ionic, Cordova, ...), or with the help of Hybrid or Native technologies. 

Well, that escalated quickly. Let's go through it nice and slow.

I mention the SPA first. It is an app that runs in a web browser and dynamically generates and updates its content without having to refresh the page. Everyday examples include Gmail, Google Maps, Netflix, or HBO GO.

Then there are PWAs. These are web applications that have additional functionalities beyond your typical web apps at the cost of minor architectural changes and the addition of so-called service workers. This means there is some extra work, but mobile users can "install" the app, use push notifications, or access some other phone functions to a limited extent. These applications are almost like native apps, except that they aren't.

I will only mention Native Wrappers in passing. They represent an intermediate stage between web and mobile apps. You take the web app, wrap it in native code, and send it to the store. There are several ready-to-use native wrappers, such as Ionic or Cordova. So with a little extra effort, we inch ever closer to going native.

As for hybrid technologies, we had been giving them a pass for a long time at Applifting. We had a few unsuccessful runs with Xamarin, so it was a closed chapter for us. We skipped React Native altogether, and it was only with Flutter that we jumped back in. Therefore, whenever I talk about hybrid technologies in this article, I focus primarily on Flutter. So how does it work? You write one code and then build the app for both platforms, Android and iOS. A pretty interesting way to cut costs.

And last but not least, you can opt for a purely native approach which works with two codebases, Swift for iOS and Kotlin for Android. The overhead expenses might be on the more expensive side of native development, but you get everything you could ask for from a mobile app.

Are things starting to make sense now? It might be a bit too vague at the moment, so let's rest for a while. Next time we'll take a look at the pros and cons of each of the approaches above. I believe it will definitely start making sense once we get into that.

When, Why, and How to Go Mobile: What options do you have?

Who is in charge of approving purchases of equipment, licenses or participation in conferences within your company? At Applifting, it's all of us. We all have the power, and at the same time responsibility, to take decisions about the things that matter to us.

To help Applifters old and new with these decisions, we have set up an  Advice Process. How does it work? In short, there are just three steps: "I identify a need", "I consult" and "I decide". At the consultation stage, we turn to those who will be affected by the purchase. 

At the same time, we ask Applifters who have expertise in the relevant field. We do not have to follow their advice strictly, we can go against it. But we should have very good reasons if we do so and we must choose what we consider to be the best course of action. The final decision and responsibility for it lie with each of us.

Price plays an important role in the advice process. The higher it is, the more people we should consult first. If it is a matter of a few hundred crowns, an Applifter can take that decision alone. If it is a more expensive item, worth a few thousand crowns, we must consult with at least one colleague. Purchases worth tens of thousands must be discussed with more people, ideally including a member of our Council of Elders. And beyond that, it is essential to ask more colleagues for advice and to include the Council members.

In general, the more people that will be affected by your decision, the more people you should seek advice from.

This Advice Process mainly concerns the purchase of licenses, participation in conferences and the acquisition of equipment. In the future, however, we plan to expand it to other decision-making areas.

Do you like our purchase system and would you like to implement something similar in your company? Get in touch with us by phone, via Facebook, Instagram, LinkedIn or Twitter. We will be happy to discuss this with you and advise you on how to get started.

The advice process: When a colleague approves your purchase

How do you decide on starting a new project in your company? In Applifting, we do it publicly and together. We want to participate in those projects that make sense to us from an ethical standpoint, which is why everyone’s opinion is important to us, even if it means not going through with the job.

Everyone who comes up with a potential business must summarize it in a few points and present it in a written form. This applies to anyone, including Applifting's owners. We all then have the opportunity to comment on it, support the project or reject it.

It is essential for us that the client and the desired product comply with our ethical principles and are in line with our mission and vision. What exactly does that mean?

The app is meaningful and helps someone to have a better life 

It must be a good fit for our people. The project must spark joy for Applifters 

The app will move the customer closer to their goal 

There must be a clear value added for the end user

If there is one or more dissenting opinions, we will sit down with these colleagues and discuss their comments face to face. Sometimes it is just a misunderstanding, or some details need to be clarified. If so much as one Applifter is categorically opposed, however, we give up on the project.

Do you have a similar opportunity in your company to comment on future projects or otherwise influence your business strategy?

New business: Everyone has the right to speak their mind

The end of 2019 left us with a lot of motivation and bold plans for 2020. But then the COVID-19 pandemic changed everyone's plans, including ours. Nevertheless, last year was absolutely a success in our book. We managed to expand to the UK, move to wonderful new offices, and welcome 40 new Applifters on board.

One of our ambitions for 2020 was the expansion to the UK. We had to postpone the original April opening date for our London branch due to the coronavirus situation. Fortunately, with only half a year’s delay, our colleague Jan Hauser set out to conquer the British market in October. He set up shop in Level39, a community space for startups and leaders in cybersecurity, fintech and retail tech.

It has been a bit of a rocky start, though. We were the new kid on the block in an unfamiliar competitive environment. Not to mention the whole country being in lockdown, making it very difficult to establish important contacts and connections. But even so, we managed to get in touch with more than 100 people, and we started cooperating with our partners. We predict the first quarter of 2021 to yield our first success.

Despite the raging pandemic, we did a little spring cleaning and moved to our new, significantly larger (and much lovelier) offices in Karlín. Seeing as we spend a lot of time at work, we wanted everyone to feel at home there. Whether you prefer open-plan offices or the more traditional private ones, you are free to work wherever you please. We also have some really cool computer game themed meeting rooms, a zen room, an event space, and also a game zone with a PlayStation and table football. And even though we did not have many opportunities to enjoy our new offices last year, we are excited about and looking forward to being able to see one another in person again.

We were excited to unveil our new brand last summer. In addition to a fresh new logo, we also introduced a completely new brand identity that is more in line with current trends and really fun to work with. The cherry on top was the autumn launch of our new website.

2020 was a turning point for us in that we realized how fast Applifting is growing, and how the constant increase in our headcount has its downsides too. The more of us there are, the more information there is  to absorb. Therefore, we decided to break down the structure and reduce the cognitive load by dividing it into smaller teams called tribes. The  first tribe to test the waters were DX Heroes, and now we are seeing the start of a second tribe in London. This year should see that number go up.

And last but not least, we managed to introduce the so-called advice process. It helps us facilitate purchase of new equipment, licenses or conference tickets. We have transferred the power to make decisions and the responsibility that comes with it to Applifters. The process is simple: identify a need → consult it with others → make a decision. An important thing to consider is the impact of the decision, as well as its cost. That is, the higher the price and the more people affected by the outcome, the greater the number of Applifters you have to turn to for advice. 

For items in the order of hundreds of crowns--go ahead, call the shots. Once we are talking thousands of crowns, talk it over with at least one other person. Is it even more expensive? Then it is right to discuss it with the members of the Council of Elders. Thanks to the advice process, each of us has responsibility for the things we care about. 

What follows afterward is applying this to other areas after a trial period of sorts. So far, we are still in the learning phase, but we are happy to report that we have not had any major problems in about half a year of operation. No money lost, no misplaced invoices. Freedom and responsibility have triumphed once again. 

The pandemic delayed some of our goals and postponed the implementation of several pre-planned orders. On the other hand, it accelerated the development of Applifting and showed us that we are fully able to work remotely. We are trying to look on the bright side of things with the hope that this year will be much better and even more successful.

At Applifting, we like working on things that make sense and help improve life around us. One such project is ”Zalej mě”, an initiative from Brno on which we started cooperating in the spring of 2020. Its core idea is community care for urban greenery, specifically watering trees.

Anyone who cares about their surroundings and wants to actively contribute to improving them can participate in the project. Here’s how it works:

Start by selecting one or more trees in your vicinity, on the interactive map on the Zalejme.cz website;

Check the watering and precipitation data and the coloured watering level indicator;

Go back to the map and add in the date of watering and the amount of water.

That's it! Nothing complicated yet very useful. This is exactly what we like about the project. In addition to Brno, the project is already up and running in České Budějovice, Litomyšl and Tišnov. The founders are now working to expand to other locations.

Read how our collaboration came about, from the project’s founder, Michal Polanský:

“The development of the Zalejme.cz initiative has received a huge boost recently thanks to the support we have received from Applifting and its programmers. This story actually began much earlier, with the HeroClan initiative. HeroClan connects volunteers with expertise in IT, marketing, graphics, etc. with non-profit organizations that need their help. I turned to HeroClan when it became clear that our existing application had reached its limits and needed to be developed to a higher level. 

I thought that volunteers would sign up to help in their free time, which is what had happened before. But what happened next significantly exceeded my expectations. Tomáš Landovský from the Prague-based IT company Applifting, which develops professional web and mobile applications, called me. Applifting has vast experience in this area and also a very supportive approach to its employees. When they are not busy working on a commercial project, they can choose from a variety of internal or public benefit projects to work on. 

Tomáš offered to make Zalejme.cz one of those projects. However, he first wanted to make sure that the idea of ​​watering trees really made sense to people. So he made the trip to Brno, and together we asked random people in Brno's parks how they perceived the state of the public greenery, and whether they would be willing to do their bit from time to time to water the trees. They were all very enthusiastic about the idea, so Tomáš joked that I must have had a secret agreement with them ;-)

After that, there was nothing to stop us from starting to work together, and before long a great team of three programmers from Applifting were working on the project - Lukáš Knápek, Jiří Hájek and Marina Jakčin. 

Within a short time, they had put together a new version of the map application, based on the latest technologies. The change is obvious at first glance. The map loads much faster, users have a new interface, the trees in the map are colored according to their watering and precipitation level, and some other new features have been added too. I am sure that we will be completely ready for full operation in the spring (2021). 

I am very grateful for the generous support we have received from the Applifting team, who have not only dedicated their working hours to the development of our application, but have also helped us in their free time. Many thanks indeed to them, and I am looking forward to our further collaboration.”

Zalej mě: A meaningful project that we really enjoy

How  do you test your apps before release? At Applifting, we try to have a  tester on every project who ensures that the software we supply is top  quality. Quality assurance (QA), and especially the testing it involves,  is a very important element in product development, as we know from our  experience here at Applifting. Unfortunately, it is also the most  frequently overlooked step in the process.

Many  companies don’t have a clear vision of how to deliver high quality  applications. We often come across companies where the quality of the  product rests on one “clicker”. He usually has his work cut out just  handling cards in JIRA in order to implement all the new features by the  end of the sprint. When releasing a new version of the application, he  doesn’t know where to start with making sure the application works  really well and is “bug-free”.

We  know from our experience that testing has a huge impact on development.  If we release an untested or poorly tested application, it can  negatively affect customer satisfaction, which can result in losing  users and thus money.

In  general, if the tester “clicker” has to do the same tasks repeatedly,  s/he will get “work blind”, and liable to make more errors. Luckily, a  lot of the tester’s work can be automated, making the results faster and  more accurate and enabling the tester to focus on a smaller number of  the most important tasks.

The  most common problem in this stage is that testing staff do not invest  enough in self-education. As a result, many testers either stagnate or  move into development roles instead. When the most experienced testers  shift their focus to development, this leads to a lack of experienced QA  experts in the labour market and slows down improvements to the testing  process.

If  you ever meet a senior QA engineer, s/he will probably be a consultant  for large companies. Consultants like this do not usually push for big  changes because it is difficult to convince managers of large  corporations to adopt new methods and approaches. Yet although it is  true that changes to the process initially require a slight increase in  investment in QA, they save time and money in the long term. Continuing  to work according to proven, established principles, remains slow,  inefficient, and more expensive in the long run.

How  can we escape this vicious circle? The best advice I can give from my  own experience is not to be afraid and to have an open mind to new  things and approaches. I can certainly recommend trying the BBD approach  to software development in your company — I will tell you more about  this shortly.

At  Applifting, we keep up with technology and strive to incorporate the  latest methodologies and tools that emerge in QA into our development  process. We look for the latest agile methods and hunt out new tools so  that we can move both ourselves and our clients forward.

Our  goal is to deliver consistently high-quality software. How do we  achieve that? Through continuous testing! Using the latest tools, we do  our best to ensure CI / CD / CT: continuous integration, delivery, and  testing. Why? By continuously testing the software we are developing, we  avoid unnecessary delays in releasing the application and ensure fast  feedback on the development in the current sprint.

What are the benefits of continuous testing?

Proper coverage of the tested product safeguards against most business risks.

Realistic evaluation of user experience and analysis of the impact on the end-user.

Preventing the occurrence of critical errors on the customer side, which could reduce trust in the product.

Less pressure on the tester before the application is released. Feedback at every stage of development.

How  acceptance conditions for the release of the application are set up (if  it does not pass the tests, the application must never be launched and  never reach the user).

Continuous testing is part of the pipeline and DevOps tools.

It is important to have the test data set up correctly and the test environment ready.

The testing process must be continually optimized and business risk coverage maintained.

Of  course, continuous testing will not save you on its own. But properly  safeguarding against business risks through automated testing gives  testers time to focus on more complex issues and think about in-depth  testing strategies.

BDD  (Behavior Driven Development) approach is one interesting modern  software testing methodology. It emphasises the importance of involving  development staff and the product manager in the process of ensuring  high quality software delivery. According to BDD, test scenarios should  be defined in cooperation with the product manager, the developer, and  the QA / tester.

faster understanding of the product manager’s requests,

faster and more accurate implementation (frequent fixes are not necessary because misunderstandings are eliminated),

the tester has a job to do at the beginning of the sprint.

An  undeniable advantage here is that BDD uses a DSL (Domain Specific  Language) in test definition. This language is called Gherkin and is  understood by all involved. Thanks to this, the product manager can be a  full member of the team, participating in meetings and contributing to  the discussion. This means the team as a whole is more involved in  determining the quality of the delivered software and thus a better end  product is created.

This  was just a small insight into what we do at Applifting to deliver top  quality software and keep up with the latest technology. If you are  interested in any of the methods and procedures we have mentioned or you  just want to have a chat about how to streamline your QA department,  please don’t hesitate to contact me.

Damian Gorný, damian.gorny@applifting.cz

Testing: An important part of the development process

In the previous articles,  we discussed how to turn an idea into a product. Let’s have a look now  at what the pitfalls could be once your product has got some traction.

If  we are lucky and our product succeeds, we next have to deal with  scaling problems. The company’s capacity, its supply chain, its  technical solutions and support mechanisms have to deal with increasing  demands from customers. If your solution involves too much technical  debt or your company operations are not ready, you can quickly end up  frustrating your customers and losing their interest. So even if it is  tempting to stimulate demand, organic growth is usually much safer as it  gives your company enough time to accommodate the changes required for  successful scaling.

There  is also a danger of what is known as premature scaling. When an  innovative product first hits the market, it is primarily purchased by  innovators and early adopters. According to the Diffusion of Innovations theory,  this group of customers represents approximately 16% of the market. The  product needs to move beyond this category and penetrate the early  majority before we can assume that it is suitable for massive scaling.  The early majority group, however, is quite different in character from  innovators and early adopters. Early majority users are less tolerant of  bugs and less excited about sacrificing anything (UX, integration,  polish, etc.) in return for early access. So it is important to validate  every product with the early majority group, otherwise you run the risk  of premature scaling.

When  a company sustains its growth and manages to scale up, there is another  trap. It is tempting to introduce more structure and controls in an  attempt to demonstrate to investors that the company is well-managed.  This usually kills the organisation’s agility, disconnects its employees  from real user problems, emphasizes productivity and management by  numbers over creativity and leads to employee dissatisfaction and  disengagement.

To  stay innovative and keep the startup spirit, the organization must be  agile. The spirit, trust, enthusiasm and values the company had when it  operated from a garage and had 15 employees must be retained as it  scales up. There is no golden rule for how to achieve that but at Applifting the principles of Teal organizations, described by Frederic Laloux in Reinventing Organizations, served as a great source of inspiration.

When  a company’s management staff become obsessed with numbers, stakeholder  value and short-term gains, they often lose track of their purpose and  vision.

Kodak,  the original leader in the photography and film industry, provides a  good example of this. A Kodak employee, Steven Sasson, actually invented  a digital camera in 1975. His boss didn’t see any potential in the  prototype, but allowed Sasson to continue his work on the project. In  1989, Sasson and his colleagues came up with a fully-fledged DSLR  camera, but Kodak’s management at the time decided to abandon their idea  out of fear that it could destroy their film camera market. When the  digital shift happened anyway, it hit Kodak so badly that the company  almost disappeared from the market. Had Kodak stuck to its original  vision: “You press the button, we do the rest”, they likely would have  remained dominant and certainly would have been the first on the market  with a digital camera.

The  organization has to live its vision, the vision must be more than just a  text written on the hallway walls or in presentations. This means the  company should use its vision in its day-to-day business as a bar  against which to judge the decisions it makes. At Applifting  we use our vision and mission to justify every project we get involved  in and anybody in the company can challenge our proposal and veto our  involvement, if they believe that the relationship is not strong enough.  If you trust your people and give them the chance to pursue the vision  on an everyday basis you can be sure it will not get forgotten and does  not fade out.

Scaling Problem: Why Kodak stayed analog and people went digital

In previous articles  we talked about the necessity of vision and product validation. In this  article we will look at how product discovery and product delivery  support the product validation process.

Product discovery helps us to answer the following questions:

Will users buy the product? Does the product solve a real problem?
(market research, competitive analysis, surveys, etc.)

Can users work out how to use the product? 
(prototyping, user testing, user experience, A/B testing)

What are the product’s limitations and obstacles? 
(time, money, technology, design, brand, supply chain, resources, knowledge)

Given those limitations, is it feasible to develop the product?

What are the risks and how we can mitigate them?

It  is important not to get product discovery and market research confused.  Market research can be a useful technique during the product discovery  phase but it is not a silver bullet. Nokia based their product portfolio  on detailed market analysis and a classification of mobile phone users  into four categories, each with has several subcategories. They tried to  address a specific product series to the needs of each subcategory’s  users, but this led to an overwhelming and fractured product portfolio.  Because Nokia stopped viewing mobile phone users as a holistic group, it  lost its focus. What a relief it was for everybody when the iPhone  arrived to point the way forward.

While  market research can provide us with useful information, it is not the  only available technique and it can sometimes be a bit misleading. Other  techniques we can use to expand our idea and understand the context of  our target audience include, for example, Jobs To Be Done.  I personally like this approach as it enables a company to look at its  idea from different perspectives. It also avoids asking the potential  users such obvious questions as: would you like this product?

Instead  it suggests looking at four different forces that will guide potential  clients towards or away from the product. Those forces are: push (a  current struggle), pull (a vision of a better life if the struggle is  gone), inertia (habits that prevent change), anxiety (fear of change and  its impacts).

As  an example, we might think about a cyclist who has reached a certain  age and can no longer afford to go on trips with his younger friends.  This is a clear struggle. If we remove this struggle, his life will be  better again. The right product in this case could be an e-bike.  However, some older cyclists may not feel they need an eBike yet. This  is their inertia. If you want to convince them to switch you should show  them how much less tired they would be after riding an e-bike and how  much they would enjoy it. Anxiety factors might be the price or the  limited capacity of the battery. Understanding how these forces interact  helps us to answer that original burning question indirectly.

There  is something innately intuitive and seductive about the idea of  developing the perfect product on the first attempt. It might seem like  an obviously cheaper and faster option. In reality this approach is only  cheaper if you know exactly what your clients will use and pay for.  Speed is only your friend if you are on the right track. The most  expensive way of finding that out is to develop the product and show it  to your clients.

The  safer, cheaper way is to humbly acknowledge that knowledge comes  through experimentation. This is the principle behind Agile development,  e.g. Scrum.  In every iteration, the most promising ideas are addressed and  validated quickly and cheaply. The whole agile development team  understands the goal and works creatively to find, within a short time  frame (a week or two), a way of implementing a minimal version of the  product, which can be used by real users. In later iterations, ideas  that prove successful during this validation can then be advanced and  improved.

Delivery  and discovery go hand in hand. Discovery generates input for delivery,  which makes use of it in implementation and validation.

In  2001, the Segway entered the market, hoping to transform transportation  as the iPhone had transformed telecommunication. Its founder, Dean  Kamen, and its investors had high expectations. But it didn’t succeed.  One reason for this, identified in the failure analysis, is that the  Segway was designed and developed in isolation, without feedback from  its potential users.

In the next article we will look at success traps. Stay tuned.

Product Discovery: Why Nokia drowned trying to please everybody

In the previous article I talked about the importance of having a vision for product development. Today I will look at why we need to validate our ideas.

Once we have a vision we can start brainstorming products or features which we could use as vehicles to advance it. The only goal at this stage is to generate a lot of ideas. Once we have those we then face the difficult task of deciding which ideas have real potential and which do not.

In  2009, the Avatar movie revealed the power of 3D technology in cinematography. 3D TV looked like a logical step forward and TV  manufacturers jumped on that as the next big innovation in the TV  industry. Yet by 2017, it was quite clear that 3D TV was dead. The fanciest feature is not always the right feature. Any innovation needs to address its users’ needs, fix their problems and bring them added value.

Some people say, “Give the customers what they want.” But that’s not my approach. Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, “If I’d asked customers what they wanted, they would have told me, ‘A faster horse!’” People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.

- Steve Jobs

3D  TV died due to a lack of relevant content, the need to wear special  glasses, the high price, and the nausea the 3D experience induced in a  fairly large minority of users. What worked in cinemas as an occasional  experience was not suited to daily use. Apparently, people were happy  enough with standard TV and were not willing to tolerate those  disadvantages in exchange for a 3D experience.

So  how can you make sure users will like a new product? There is no easy  answer. You have to be prepared for the sad fact that more than 50 % of  the new ideas you come up with will lead to a dead end. To avoid  spending big money on something which lacks potential we need to  validate our idea and hypothesis. Effective validation relies on  obtaining relevant feedback from the user audience while spending  affordable money.

In  the next article we will talk about agility and how to utilize Product  Discovery and Product Delivery to validate hypotheses and build the  product iteratively.

Validating Ideas: Why TV makers wanted 3D but customers didn’t

Any venture must be based on a clear, sound and inspiring vision. Simon Sinek, author of bestselling books such as Start with why and Leaders eat last,  calls this vision a “Just Cause”. Without knowing why we are making the  product and whom it stands to benefit we set ourselves up to fail  regardless of the product’s features.

A  Just Cause is a specific vision of a future state that does not yet  exist; a future state so appealing that people are willing to make  sacrifices in order to help advance toward that vision.

For something — affirmative and optimistic

Service-oriented — for the benefit of others

I like Simon’s definition, especially where he says: “people are willing to make sacrifices”.  People do not always expect a perfect product or service from the very  beginning. Those who identify with the Just Cause are willing to  tolerate some level of discomfort.

In  2016, a startup called Juceiro released a fancy product called the  Juceiro Press. Juceiro’s concept was to repeat the success of Nespresso  (see also: Keurig) capsules and to provide healthy, organic juice  without the need for manual preparation from whole produce. Juceiro  Press was a WiFi-connected juicer that used single-serving packets of  chopped organic fruits and vegetables. The machine’s only function was  to check whether the packet was an original Juceiro product, and that it  had not exceeded its expiration date, and if so, squeeze it into a  glass. The machine did not work without an internet connection and it  cost $400. The startup received $120 million in venture capital funding  from investors, including Google.

We  do not know what Juceiro’s original Just Cause was, or whether they had  one. It is certainly no bad idea to ease access to healthy organic  juices and thereby help people to live healthier lives. However, if that  was their Just Cause it is quite strange that they decided to advance  towards it by developing a product whose only function was to squeeze a  bag of raw ingredients that could be pressed manually to similar effect.  This Bloomberg News article includes a video demonstrating the difference between the machine’s product and hand squeezing.

Stay tuned for the next article, in which we will focus on Product Validation.

Previous article: Product Development: Why Google Glass failed and other products succeeded

Missing the Vision: Why capsuled juice was a flop while coffee succeeded

Do  you ever wonder why some companies skyrocket while others fail? Even  companies like Apple, Microsoft, Google, and Amazon started small,  fuelled by their founders’ enthusiasm. Everyone knows the companies that  have succeeded, but for each of these blue-chip stocks there were  another 100 or 1000 promising companies with interesting products  championed by clever enthusiasts that ended up bankrupt.

Even  the most successful companies regularly develop products which have no  real success or traction. In 2006, Microsoft introduced the Zune MP3  player, which was designed to compete with the wildly-popular iPod. That  product was discontinued in 2011, shortly after the release of its  third generation. In 2014, Amazon attempted to enter the smartphone  market with the Amazon Fire Phone. Despite significant investment in its  development, the Fire Phone did not prove competitive and was withdrawn  at a loss of $170 million — a mere drop in the bucket for Amazon. In  2013, Google released Google Glass, a fancy gadget with limited use  cases and an even more limiting price tag. This project was suspended  less than two years later.

Products  may fail for a variety of reasons, even if they are excellent, unique  and innovative. It’s easy to be fooled into thinking a product will make  it, and ignore otherwise obvious signs. Under pressure from investors,  it can be tempting to escalate prior commitments, hope for the best and  keep flogging a horse that has been dead for months.

If  big, successful companies experience failures despite having access to  the best engineers, marketers and designers and sufficient capital, what  is the recipe for true success? The answer is that product development  is inherently risky and the only way to achieve success is to minimise  the impact of any failures that do arise.

Success consists of going from failure to failure without loss of enthusiasm. 
Winston Churchill

At Applifting  we believe that failure is an inevitable part of what we do. If our  hypotheses were always correct we wouldn’t learn anything new. However,  there are certain failures we can avoid, as others have made them for us  and we wouldn’t stand to learn anything from repeating them ourselves.

In  this series of articles I will walk you through the various stages of  product development and their common traps. I begin in the next article  by talking about the importance of the product vision. The following  article will be devoted to product validation, the fourth to product  discovery and delivery, and I will close the series by discussing  scaling and vision fading.

For  each of these product development phases, I will refer to famous  examples of failures. I do this with no intention of judging the people  behind those products, but solely for the sake of learning from their  mistakes — without knowledge of these cases it would be all too easy to  walk the same path.

Product Development: Why Google Glass failed and other products succeeded

Which  tribe do you belong to? In time, asking this question will not seem odd  at all in Applifting. No, we haven’t lost our minds; we are simply  beginning to divide into smaller teams, the so-called tribes. How does  it work and why are we doing it?

Applifting begins to be divided into individual tribes. But the strong bond remains.

Applifting  is growing at a rocket speed; the number of Applifters has increased by  almost 50 % in the last year. This is a positive trend, but, on the  other hand, it brings new challenges that we need to face, one of which  is the potential inconvenience of knowing 120 other Applifters. That’s  why we came up with the idea of ​​splitting into smaller teams. We know  from experience that the ideal group size is around 30 people. All  members still know each other on a personal level and everybody is aware  of other people’s tasks and responsibilities.

Applifting  should therefore eventually begin to split into separate, independent  units. These have a few things in common, namely Applifting; its values;  shared teams such as marketing or back office; but also the Council of  Elders, the only governing body so far.

Read.Learn.Enjoy.

Read.
Learn.
Enjoy.