Category: Business and Startups

  • Mobile or web application  – which one does my business need?

    Mobile or web application – which one does my business need?

    Mobile or web application – the big debate

    When starting out, founders often have a strong idea about what channel their new venture should use. The two most popular ones are mobile applications and web applications. We know that these technologies have been used for a few years, but it is worth it to explore what the technological limitations, human behaviour and product-channel fit will be for the startup.

    If you only have a hammer, every problem looks like a nail

    With well-established technology in both spheres, software developers are able to build cross-platform mobile and web applications. Yet, with the resource restrictions (financial, time and people) on startups, it becomes exceptionally important to minimise wastage – and researching the pros and cons of all channels before making the final decision.

    All things considered

    I want to make fair mention that you need to consider each platform, different infrastructure and marketing channels for the platforms. For example, you need to look at:

    • Infrastructure costs
    • Customer acquisition models
    • Market segmentation and technological compatibility
    • The financial impact on the startup or small business

    I am of the opinion that you should have empirical proof from your customers before you code a feature. The same is true for choosing a platform. Don’t just choose a platform on a feature or system without testing the outcome!

    Mobile or web application: A channel architectural overview

    The cross-platform technology for converting a single code set for use on the web, mobile phones and tablets is not as mature as for example the cross-browser support that JQuery and Bootstrap offer all web browsers. There are a few coding frameworks that offer a general one-size-fits-all solution but can create unforeseen technological stonewalls and issues. These may range from scrolling issues to unsupported features.

    Generally, the server allows shared business logic between a mobile app and a website. The browser and mobile app tend to be a lightweight ‘shell’ with very little business logic. This allows for server code reuse and decreases platform specific issues and bugs.

    Choosing a mobile app

    When deciding on a mobile application as your chosen channel, cost and business niche are the two biggest considerations.

    Certain business models need to have an app available on-the-go. For example, it makes sense for a pick-up and delivery solution, such as Uber, to be on a mobile phone – you need access to it wherever you are.  In another case, it would be convenient to have a mobile app, but not essential to the business model. Examples include an informational service (such as an article repository with only a few articles) and services that are used less often (such as motor vehicle registration).

    It is not unheard of that people delete an app if the internet connection is lost in the app, a UI alignment issue is not to their liking or the app experience is not exactly what they are looking for.

    Mobile app users are not forgiving.

    Considerations for mobile apps

    Mobile apps, though perceived as the holy grail, can sometimes sink a startup The following factors need to be considered:

    • Users on the store rate your app and leave reviews – customer service is vital in resolving issues. Even though cross platform technology allows catering to many phones and tablets, it is impossible to cater for everything.
    • There might be a substantial amount of red tape to cross before you launch your app. For example, legal paperwork and login details would need to be provided and certain approvals need to be handled.
    • You will set yourself at the mercy of the store. If they update their terms of service, your business model might be affected.

    A mobile app also has a financial impact on your business:

    • Mobile app development tends to be more expensive to code. It can also become very complex really fast.
    • All payments need to be handled by the store. The standard charge is around 30% of gross payment
    • Annual fees payable to the stores – some stores have a once off fee, whereas others have an annual subscription fee to host your mobile apps
    • Server costs and infrastructure – in many cases, only half of the business logic is on the mobile app. The other half is on a web server that the mobile app connects to.

    In my personal experience, the only features I have seen that make a mobile app different from a web application is push notifications. Though Android does allow for web push notifications,  iOS doesn’t allow for this at the moment.

    Choosing a web application

    Web applications are more mature in technology than mobile apps. With code libraries like bootstrap and jQuery and Angular coders can create cross-platform single page applications or progressive web apps for online and offline use.

    Though web apps are versatile and easy to deploy, the issue of trust can be difficult to overcome. There is nobody that can verify the legitimacy of a website.

    Websites are also easily forgotten and not bookmarked. Retargeting and customer communications are vital in turning them into returning customers. In some cases, it makes sense to use web push notifications, but might be seen as spam by some.

    Considerations for a mobile app

    Consider the following before choosing to build a web application:

    • Would you need to integrate a payment gateway? What will the cost be?
    • Do you need to send communications such as email and SMSs for awareness?
    • Which technology stack do you want to use? The .NET Framework, MEAN- or LAMP stack?
    • How much should be doable offline? Is this a fully online solution?

    Concerning the financial impact, the following should be considered:

    •  Infrastructure costs
      • Web application hosting, including database costs
      • Annual domain renewal and SSL certificates
      • Third party costs for security and validation

    Conclusion

    I realise that this article is not nearly extensive enough for all the articles available on the internet.

    For the survival of any business or startup, we need to focus on what is important and avoid wasting resources (money, time or energy).

    Though mobile apps are the go-to solution for may startups, we need to count the cost and confirm if this will serve the end goal and purpose of our proposed solution. The same can be said for web applications. Mobile applications will need to withstand the ratings, cost and fulfil the need of the user’s experience to avoid being deleted quickly.

    Valid proof is needed that your product will fit the channel – test your assumptions with your customers.

    Enjoy your business.

  • Executing your small business strategy

    Executing your small business strategy

    Reaching your goals by execution

    Susan created a startup to do document management for medium sized businesses. Having a mission, vision and execution strategy in place, she believes she is on the right track to get a product market fit – but has a problem executing the strategy that she has pinned down.

    This situation is not unique. 70 % of strategic transformations fail – and the rate of startups and small businesses failing is close behind this number. As a matter of survival, we need to measure the health of our business and then determine if we are on track to reach our goals.

    The different strategies for different businesses

    I find that there are three different types of company structures: organisations with high levels of uncertainty, businesses with a formula and big corporates. Each of these have different aims, goals and execution paths.

    Organisations with high levels of uncertainty – those doing groundbreaking work and have no existing frameworks to lead from, would require a lean build-measure-learn approach. For example, in the above startup, Susan might need to pivot at some stage. This might happen when her customers expect a different strategic alignment of her offering to their vision.

    Many small businesses have a formula that they can use to achieve their vision. This includes the insurance tech – Ubelele wrote an excellent article here on how you can use a formula to launch an insurance app (Naked, Simply, JaSure).

    You also have a corporate strategy. There are generally three strategies that are focused on:

    • Growth strategy – when a big business is looking to expand its services, products and offering
    • Stability strategy – when an organization keeps the status quo and adds more stability to its existing infrastructure.
    • Renewal strategy – if there is a decline in the performance of an organization. This would either mean retrenchment or a turnaround strategy.

    Breaking down the execution

    If you are working in an environment with a high level of uncertainty, you need to break it down into bite sized chunks. This can be broken down as many times as needed. Being overwhelmed, you need to decide on an area of focus.

    In the book “The 4 disciplines of execution”, the authors refer to a concept called WIGs – wildly important goals. WIGs are small, dial lifting changes that can be implemented to move your company forward. If you can reach this small goal, then it would have a huge impact on your business, revenue, inter alia freeing up time.

    These can be decided weekly or bi-weekly.

    Focus on small wins

    In some cases, the WIGs can sometimes be big wins – and can take two weeks to execute. Make effort to break it down into smaller daily wins. Remember – you need to motivate yourself (and your staff) to grow your business in the right direction.

    And small daily wins can serve as a great motivation

    Aligning staff members

    Though this section deserves an article by itself, I want to touch on staff and your strategy.

    Many businesses do not engage staff meaningfully. Staff members need to do the grunt work, without the a clear buy-in of the vision. Make it a priority to communicate your vision and strategy on how to get there with your staff members.

    They need to feel valued and part of the plan.

    Make sure expectations are communicated, measured and broken down accordingly.

    Align KPIs and performance to the goal – this is why you have KPIs and performance reviews in the first place.

    The power to say no

    As a small business owner, I find that there are many opportunities that come my way – anything from fun little projects, startups looking for a technology parter to large projects where you need a team of hundreds of developers.

    To align my company with the vision and strategy, I have learnt the power to say no.

    When you say no to something, you say yes to something else.

    It is not wrong to say no to a project that is easy money – you need to make tough decisions to align yourself to who you want to become. If it does not fit into your vision or strategy, then say no.

    Measure & evaluate

    No company can move forward without vision.

    Without implementation of a strategic roadmap, you will never get where you want to be. But how do you know your actions have the desired effect? Are you moving in the right direction?

    For this there needs to be a measurable outcome to your goals, mini goals and tasks. The smaller the measurement, the quicker you will be able to get back on track if you have strayed away from the main goals. These measurements can take many forms. Here are some examples:

    • Do weekly evaluations if the customers you have and attract are in alignment with your company vision
    • For software development projects – checking if the velocity and tickets align with the end goal (e.g. delivery date of a specific feature)
    •  Financial alignment with features and services added – Use dashboards to see the impact of your changes

    Conclusion

    In some cases, a formula can be followed for growth. For startups and businesses in an environment of high uncertainty, it might not be as simple as to have a clear long term goal other than client take up and financial stability.

    The key concept in reaching your goals in business is execution – we need to action our plans to achieve.

    If your goals are too big, then add mini goals. Add tasks. Add sprints.

    Be efficient in measuring your outcome. You need to know within two weeks if you are not on target to achieve your goals.

    Enjoy your business.

  • Funding for a startup

    Funding for a startup

    Funding for small businesses and startups

    You need funding to do something in your business or startup.

    You need to source the money in some way.

    Enter the funders.

    Where can I get funding?

    There are different types of funding rounds. It is not necessary to have the funding in this order, but it does make sense that one would want to try these first, as to maximise your profit.

    • Pre-seed and seed rounds – These are friends and family rounds that are often used to launch an enterprise. One could:
      • Consider a bank loan in this round, as it is not yet exchanging equity for money. The bank will charge you interest and you would need to pay back the money in instalments.
    • Angel Rounds – Angel investors or private investors offer money in exchange for ownership equity, debt (i.e. a loan) or similar. They often offer more than just money, including skills and network support.
    • Venture Rounds – Venture capital firms would invest in your company for equity and promises of returns. The venture rounds are normally named “A round, “B round”, etc. the more rounds of funding needed, the more concerned a venture capitalist (VC) would be as this would infer that the company is probably not sustainable in the long run.
    • Mezzanine Rounds – If a company is planning to do an initial public offering (IPO), i.e. list on the stock market, this type of funding should carry them until the desired outcome is achieved.

    It is worth noting that there are other options for funding as well.

    Banks sometimes approve funding for small businesses. The downfall is that they require securities – a guarantee that the money will be paid back.

    Funds, grants and government agencies – there are multiple grants and help for small businesses. These include the  Small Enterprise Finance Agency (SEFA), National Empowerment Fund (NEF) and the Small Enterprise Development Agency.

    When should I acquire funding?

    This graphic is an oversimplification of the process, which will be used a the basis of the process funding analysis.

    It is possible to get funding anywhere in the startup process. For example:

    • Idea phase: Many incubation hubs offer assistance and financial help for founders that have an initial idea.
    • Prototyping and MVP: Many people do not have the financial means to build a prototype or a minimum viable product (MVP).
    • Scaling: Once the business has been established and the business model has been proven to work, the next logical step would be to grow the business. This would cost money!

    Lean principles teach us that we should delay decision making as much as possible – until we have no other choice. This applies to funding as well. A cash injection might help your company a lot, but it might be worth it to first establish a solid foundation: automate processes and do market research and explore the costing model and channels for your product/service.  This makes sense for a few reasons:

    • It is not advisable to give your company equity away if you can avoid it.
    • Your investors become your boss. They want to see a return on their investment!
    • Many companies want early funding for their idea

    Conclusion

    Finding funding for your business can be complicated. Depending on where in the process you are, you might get away with asking friends or family for the cash you need for your business to survive.

    In other cases, you would need to speak to venture capitalists.

    Ideally, you would want to keep all the equity. Bootstrap your company as much as you can.

    And start raising equity when it will benefit you financially.

    Simply be effective.

     

  • How to find a product/market fit and the four fits framework

    How to find a product/market fit and the four fits framework

    Finding a product/market fit is hard.

    Finding a product/market fit for your product or services is not easy. Sometimes it is like trying to fit a square peg in a round hole. It might sound as simple as connecting your service or product with the right target market. With a new product or service, this might be more complex. For example:

    • You might have the right target market and the wrong product or vice versa
    • A subset of the product might fulfil their needs or a bigger solution might be required.
    • The product might have indirect competition that is upheld by ideological constructs.

    There could be an array of things that could be wrong and discovering what the issue with the fit is could take quite a few iterations.

    Testing for a product/market fit

    Eric Ries famously defined a startup as ” …a human institution designed to deliver a new product or service under conditions of extreme uncertainty…”. As most small businesses of a startup nature don’t know where they fit in, it would make sense to use the build/measure learn cycle.

    We all need to accept the fact that we don’t know what we’re doing. We need concrete proof of what we assume. With any product, we could easily assume hundreds of things, including:

    • People would want to use our product
    • People would be willing to pay x/month for our service
    •  Our product is backed by a blue ocean strategy. 

    Working with our assumptions and getting substantial proof that this is the truth is central to getting that fit.

    Validate your assumptions

    Assumptions can be validated with different indicators:

    • Qualitative 
    • Quantitative 
    • Intuitive 

    The channels of validating your assumptions appear different, depending on your business model, product and channels you want to use.

    As there is not a one size fits all, I would like to use some examples to illustrate how one can validate assumptions:

    • Advertising and idea validation: Testing interest might be as simple as putting up a splash page and running a Facebook ad campaign
    • Existing products/Adding new features: Adding a menu item in your existing product or website to see if your existing userbase wants the new product or service.
    • UX/Usability validation –  Contact sessions with a core group with Copic marker mockups

    By iterating (learning), a better idea can be formed about client expectations and requirements. The art is to do this as quickly and meaningfully as possible, so not to exhaust financial resources.

     The four fits framework

    Brian Balfour wrote about the growth framework. A $100 million company needs to consider four aspects and how they fit together:

    • Product/market fit – does your product fit into the market that you are targeting?
    • Model/Market fit – Your engagement model will show if you need one big customer or several smaller customers (i.e. the market).
    • Channel/Model fit – your engagement model should fit in with your channel. If an advertising model is used, then the ROI model should be sufficient for the channel.
    • Product Channel fit – Whichever channel (Marketing, APIs, Technology) you decide to use, you need to follow the rules. Your product needs to fit into the channel, as you don’t play by your rules, but by theirs.

     

    Using this framework, one can scrutinise each part of the startup assumptions and validate if this would be feasible and if one would need to explore other indicator options.

    How do I know if the product/market fit has been achieved?

    Achieving Product/market fit means that the product/service does not require additional changes or pivots. The market, model, product and channel have reached a sweet spot.

    There are a few metrics that can assist in deciding that product/market fit has been achieved:

    • The 40% rule – If 40% of the customers indicate that they would be “very disappointed” if they could no longer use the service or as a “must-have”.
    • Online metrics – Most of these metrics can be tracked through Google analytics
      1. Low bounce rate – i.e. the customer expectations are met
      2. Time on site
      3. Pages per visit
      4. Returning visitors – i.e. the impact of your product or service is so big, that they keep on coming back for more.
      5. Customer lifetime value 

    Conclusion

    Understanding the assumptions that are made concerning your product/service will guide you in testing your idea. You need to have proof that you’re on the right track.

    Using the four fits framework, you can establish if you have a good fit in product, market, model and channel.

    Finding a product/market fit is not easy – but worth the journey.

    Simply be effective.

    Sources consulted

  • Do you really need funding?

    Do you really need funding?

    Funding: a quick answer

    Founders and small business owners request funding for many different reasons. In many cases, they have done their due diligence and have proven a product/market fit.

    Many people want to get funding, as this takes the liability off themselves and onto the funder. For others, they would like to scale their company to make more money.

    Though there is not a one size fits all, it is worth exploring all avenues before going the funding route.

    What other options do I have before I get funding?

    The other day I spoke to a lady that asked me for a small loan. She needed R 5 000 to get her business off the ground. I decided to rather take the route of asking questions on how to bootstrap her business. It came out that she wanted to buy stock and wasn’t willing to start small. This was quite alarming for me, as many people want to do a big reveal of a product/service.

    Bootstrapping

    Bootstrapping allows us to learn – what do my customers want? How do they want it? How can I satisfy their needs? We know from success stories such as Netflix and Airbnb that learning is essential to success – and pivoting where needs are.

    A company of one

    Our culture is obsessed with “Bigger is better”. For this reason, Paul Jarvis wrote in his book “Company of One” that we should consider staying small and not scale for the sake of scaling. Explaining that large businesses have more overheads such as an HR department, legal and change management, he noted that his business was able to survive through recessions and bad times.

    While staying small might not be the goal, it should be considered building relationships with customers, automating anything that is eating away at your time and optimising the business process.

    Pre-selling your product or services

    In some cases, you need money to grow. It is an option to test the viability and raise capital by pre-selling your products. There are multiple online platforms that you can sell your products, including Indiegogo, Kickstarter and GoFundMe.

    On the other side, many software people sell products even before they are developed. Giving the customer HTML/CSS mockups, and/or working with the clients to develop the solution might bring cash flow to a business.

    Minimum viable products (MVP)

    For a startup, it is vital to get your first paying customer. With an MVP, you have something to show potential clients and start the learning cycle.

    The biggest issue today with entrepreneurship and code is not building products inefficiently. It is building products nobody wants very efficiently.

    Breaking down requirements can point the founders to what is important to customers. This could cause the MVP to become the product, eliminating the necessity for funding, which would only be required for scaling at a later stage.

    What should happen before seeking funding?

    At some point, a business might require funding. As the goal of a startup is to find a product/market fit and then scale aggressively, it makes sense that funding will be sought as soon as the tipping point is reached.

    In some cases, such as accelerator programmes, the money will be given upfront, with guidance and mentoring.  With most of the startups in South Africa, the scarcity of funding options requires a certain level of innovation and certainty that the offering will deliver on promises of profit, value and expectations.

    The European Innovation Academy identified steps before raising capital. Though these steps are not cast in stone, it is interesting to consider how much needs to happen before getting venture capitalists (VCs) or other funders involved.

    In my experience, startups try to get funding before proper validation (both product/market fit and market research) has been done.

    Though I am not oblivious to the fact that sometimes economies of scale will determine the profitability, it is recommended to keep the business out of the hands of strangers as long as you can, as funders will invest in the perceived value of the company.

    Management and expectations from investors

    Venture capitalists (VCs), Angel investors and other sources of funding will indirectly become your boss when you get funding. According to Jose Cayasso (CEO of Slidebean), investors are looking for exponential growth on their seed investment – not just a 10% or 100% return. 

    The investors will become your boss – and the aim will be to scale the business as quickly as possible so that they can get a return on investment to the investors they represent.

    As the founder, if you need to work fulltime with the startup, there will be no room for a retirement fund or luxuries. Your salary will be absolutely basic necessities. You will need to negotiate hard with your funders to justify why you need the money you need.

    Do you really need funding?

    Though this question is dependent on many factors, a few pointers should be considered before funding is pursued:

    • Has the research been done and shows a market fit?
    • Were all options for pre-selling, MVPs and bootstrapping considered?
    • What type of returns will the potential investors be looking at? Is this sizable compared to the seed investment?

    Conclusion

    Though there is no right answer concerning if you need funding, it is worth noting that we shouldn’t ask for money too fast.

    There is no such thing as a free lunch.

    Consider all the options outside of funding first. Use funding to scale a startup, rather than fund development. Is it possible to fund development through investors? Yes. Yet, it is an expensive test to see if it would work.

    Simply be effective.

  • Deliver quality solutions by focusing on learning

    Deliver quality solutions by focusing on learning

    Developers and users

    Software developers have historically been portrayed as mushrooms sitting in a darkened room. It is forbidden for them to connect with the business units. It also makes sense, as focus is needed to produce quality code.

    It is also unthinkable for a developer to contact a client directly to understand how they use the software.

    Let us shift our perspective away from the traditional silos for a while and look at the impact it would have to move developers to the forefront of the software development lifecycle (SDLC) – the gathering of requirements.

    Unused and unfit code

    Every company has a few solutions that never made it to production. Money was wasted on something that was believed to add value – but didn’t.

    Imagine the opportunity to find which part in a solution does not add value. How would the landscape change if we could stop a process that doesn’t add value before it even starts? By closing the gap between the end-user and the developer, this would be identified well in advance.

    Mary Poppendieck describes the difference between development and production. She likens development to the creation of a recipe, and production to following the recipe, with the principle differences outlined in the table below:

    Development Production
    Quality is fitness for use Quality is conformance to requirements
    Variable results are good Variable results are bad
    Iteration generates value Iteration generates waste

    Iterations

    The focus should be on learning what adds value and what is a waste. To avoid relearning, the team can keep track of all the functions in an excel file, with supporting documents in a folder in the cloud or on a shared drive.

    This should be accessible to everyone in the team.

    On a practical level, it would look something like this:

    • A feature has been requested
    • What would be the most valuable assumption that could be tested? What can we learn from this?
    • How do we code to test our assumption?
    • Can we build just the user interface without any features and check with users if the idea works?
    • Once implemented, how can we measure what we’ve learned?
    • How does what we’ve learned change our view and way forward?

    Let’s look at an example.

    A request came through for doing credit checks on multiple people at the same time to check for the affordability of a loan. It included complex email business logic depending on what your partner’s credit score is.

    In a traditional business, this would go to the business analysts that would break this down into stories to build. Within a business focused on learning, the team would question how could we test if this would add value:

    • Can we add a menu item on our website and a contact form to test if this would work? Can we track this through Google Analytics?
    • Should we include the complex emails, or can we just to the multiple credit checks for now?
    • What part of the feature will add the most value?
    • Is this feature at all necessary? How can we prove that we should build this feature at all?

    Destroying silos

    Unless the business consists of a single person, it would be best to let the team decide on how to test that the idea will be viable.

    Developers understand code.

    Business understands the requirements.

    The client uses the software every day.

    Though software developers tend to dislike meetings, it would be worth it if they assist in defining what needs to be learned and how to measure the outcome. By closing the feedback loop between the coder and the user, the learning can be accelerated. Here are some ways to do this:

    • The business analyst should have regular conversations with the coder and user to establish what would be quick wins, what is doable and what will take more effort.
    • Get developers to shadow users in a focus group
    • Have regular sessions with business, business analysts developers and users so that everyone is aligned on where the software is heading
    • Allow developers to speak to users directly when resolving bugs and issues

    Conclusion

    A business should work as a team. Work together to learn and grow.

    Avoid silos – learn as a team what will work and what will not.

    Keep track of all learning so that one could refer to it at a later stage.

    Simply be effective.

     

     

     

     

     

     

  • What is a diagnostics phase and why do we need it?

    What is a diagnostics phase and why do we need it?

    The issue with a quick quote

    When new clients meet me for the first time, they often talk about the idea that they have for a new web or mobile app, their goals, aspirations and product positioning. With product development, client expectations can be matched by a simple grid of what the product can and cannot do.

    Bespoke software development on the other hand is a bit more challenging. The client has a certain picture in his head about what he requires. Yet, requirements are never set in stone.

    As clients see their product being built, changes often creep in. In the same way, as users use the software, the client’s needs evolve.

    To avoid a mismatch of what the client wants and what the developer (or tech partner) develops, it is best to pin down exactly what is required. This is generally done in a business requirement specification (BRS).

    Once a blueprint of requirements is pinned down, a proper estimate of time and cost can be given. Tasks can also broken down into small chunks and delivered in an agile/incremental fashion.

    Understanding the requirements

    From a business perspective, it does make sense to understand what is required. However, it seldom offers insights into the end-user of the software.

    The users are often neglected for the greater vision and mission of the company, seen as a lagging factor that ‘users will get used to’. For a better view of the business and its requirements, it makes sense to include the following in the diagnostics phase:

    • Business requirements
      • Business goals for the solution
      • Timelines and output requirements
    • Expectations of the user
      • User personas – who will be using the website/software/app
      • Story flows – what would each of the users like to do and how will they achieve this
    • Technical requirements
      • API integrations
      • Third-party dependencies
      • Technology, architectural and code considerations

    The BRS – Needs mismatch

    Many clients would explain to me that they already have a BRS with a full needs analysis. It makes total sense that they would not want to pay again for another needs analysis. It would also be irresponsible of the new technology company to start solving client problems before they are engaged.

    Effectify focuses on simplifying what the clients think they need. For example, we know that a client has a 250 page BRS, a pitch deck and 10-year marketing plan for their innovative mobile app.

    With these details, we need to consider breaking down the project in smaller chunks – maybe there are online solutions, open-source code, APIs and third-party products that could decrease the time to market.

    Although the client would want to have a bespoke software solution, the need on a project could possibly be satisfied by other means that are more cost-effective, time saving and still deliver the same value.

    Conclusion

    It’s vital that the technology partner can do the job, but it is also important that you get along with them.

    The diagnostics phase is as much about requirements and understanding the business as getting to know your customer.

    Simply be effective.

  • Should I pivot, persist or quit my startup?

    Should I pivot, persist or quit my startup?

    Choosing the right response to the problem

    Every business reaches the point where what they are doing is not working anymore. Small businesses and startups can reach this point much faster than bigger businesses with more diversified product offerings.

    When any business reaches the point where they realise that what they have is not working anymore, we need to make a decision: persist, pivot or quit?

    Before we get started, let us clarify what is meant with these bug terms:

    • Persist – when your idea/business/offering is sort of working: you have some clients, but it needs a bit refinement to make the product fit
    • Pivot – you have done the refinement, but you stil cannot get a good market fit. The feedback you’ve received back from your users/potential customers doesn’t fit into your initial hypothesis and problem to be solved. You would need to radically change your problem statement, target market etc. to reapply the solution (or part of it) to someone else
    • Quit – when you don’t see any way of salvaging the solution of pivoting. Don’t just quit!

    Explore/Exploit

    In computer science, the explore/exploit algorithm teaches us the following: When something is worth it, keep on exploiting it until proven that it is not worth it anymore. When this point is reached, one should start exploring again.

    This exploring could mean three things.

    You could tweak your product offering to make it better. This is what Clayton Christensen refers to as sustaining innovation – the process of refining, tweaking and sustaining what you have. This is also the best way to optimise profit and add customer value to the existing product or service.

    If you decide to pivot, you realise that your hypothesis that you made initially was found to be untrue. In this case, you need to start with another assumption and hypothesis and retry the business in a new sphere. This could be a new target market, new (or sub) feature set, new approach or new angle.

    Lastly, you might decide to quit and salvage what you have. I refer to this as canning the project/business/startup. In this case, one might need to consider the following:

    • You have pivoted to a more successful business model, but none of these have worked. The startup is a bottomless pit eating all your money and it’s just not sustainable
    • The team dynamics is just not working – your startup team is causing division in the vision and process.
    • Other opportunities arise that are more lucrative and more sustainable

    Value innovation

    When deciding on preserving and/or pivoting, one needs to consider moving closer towards adding value to customers, while bringing down costs, effort and/or time required.

    As most startups are what Chan Kim and Renée Mauborgne calls a “blue ocean” (an uncontested market with a new innovative approach), it makes sense that these businesses should move toward adding maximum value to customers without the perception of paying more than they believe they should for the convenience

    Product Market Fit

    We know that the purpose of any startup is reaching product market fit. This means that customers want the product and are willing to pay for it. The reason that one would pivot or tweak, is to make it fit in with the feedback from the build-measure-learn cycle.

    If the offering does not fit the feedback, either tweaking or a pivot is required to make it fit. Choosing which of the two to implement depends on the degree that the initial hypothesis has been disproved.

    The pivot

    There could be a plethora of reasons that justify a pivot. In some scenarios, it might not mean that you need to rewrite the whole solution. Other pivoting options include:

    • Change the target market of your product
    • Change your business model
    • Revamp your engagement/revenue model
    • Take a subset of your existing product or service and spin it off into its own product or service

    Some of the reasons you need to consider when pivoting include:

    • Red oceans – too much competition
    • The company is not growing
    • a subset of your services/product offering is getting more traction than the actual service
    • You have changed: when the founder’s perception, knowledge (and revelation) of the market changes, it needs to reflect in the business/startup.

    Conclusion

    Choosing whether to pivot, explore or can a project or business is never easy. We are often emotionally involved and have difficulty making rational decisions.

    When considering whether to explore or pivot, one needs to consider all options including whereto, what will be at stake and how one will achieve the desired outcome.

    Don’t pivot because you can, but rather because you know the product market fit is just not there.

    Only quit when you have all the facts on the table and it’s absolutely not worth it anymore.

    Simply be effective.

    Sources consulted

  • Getting your software solution to market faster

    Getting your software solution to market faster

    When you have no time to spare

    Startups and small businesses often don’t have the budget, resources and expertise of large corporate businesses. This limitation can become the greatest strength by applying lean software development principles – eliminating waste and delivering only what the customer needs.

    Even though many developers love giving customers more than what they need in an attempt to under-promise and overdeliver. When developing for getting a product to market, all unnecessary elements need to be removed from the equation.

    This might include theming, customising, features, data filters, and other elements that might not be critically important for the customer right now.

    Needs analysis and focus

    A developer that works at a startup often needs to work long hours and deliver more than just code. To optimise the time spent as well as the effectiveness of the output, the developer need understands the customer needs to fulfil them appropriately.

    Needs can be analysed and discovered in many ways: Hotjar, Google Analytics and other tools offer us an insight into how customers interact with our solution.

    Startups and small businesses often have a low level of certainty concerning their customers’ needs. It would therefore make sense to take a leap of faith assumption and start testing their needs (and the assumptions that we make).

    Lean software development

    Lean software development is all about cutting waste and testing our assumptions about our clients, our product and the industry. The following is an outline of the process:

    1. Eliminate waste – determine what is actually important. Cut out unnecessary features or enhancements that are not critical.
    2. Amplify learning – Don’t spend days doing documentation and planning sessions that don’t deliver results. Have short iterations with regular customer feedback cycles included?
    3. Decide as late as possible – when dealing with uncertainty, it might benefit the client to create bite-sized solutions first – and therefore deferring larger decisions of the end product until more is learned of what is actually required.
    4. Deliver as fast as possible – time to market is crucial in getting user feedback. It, therefore, makes sense that any tools, plugins and other means must be used to move the project forward.
    5. Empower the team – allow software developers to make decisions about what their validated learning has proved to be correct.
    6. Build in integrity – The customer needs to be at the heart of what is done. The product must solve a specific problem. If the problem is solved successfully, it will build trust in the company and product. This, in turn, will build integrity so that the marketing, software and image all contribute to the same solution.
    7. Optimise the whole – Issues in software can damage the integrity of the software and brand. It is therefore vital that integrations with third parties, bugs and issues are prioritised on the urgent-important scale, where the most important and most urgent issues get the first attention.

    Think big, act small, fail fast; learn rapidly

    – Mary Poppendieck

    The minimum viable product (MVP)

    Many clients have the viewpoint that the only way to go to market is with a fully built product. This, however, can easily ruin a small company or startup financially.

    To the first paying client, one can create a minimum viable product to test their hypothesis and problem statement.

    For an MVP, the developer can use any means within reason to speed up output. The MVP could be something as small as a WordPress site with WooCommerce.

    One could easily test the use cases with WordPress – developing plugins and reporting for many cases. Once viability is determined and the system outgrows the MVP/prototype, a custom bespoke solution can be developed for more complex systems.

    Note that in some larger corporate solutions, the MVP might be a six-month project for a team. The focus should be on determining and developing what is actually important.

    For example, if a large life insurer would like to bring to market a tool to help financial advisors predict retirement income, a simple spreadsheet might be the first stop to see the reactions and needs of the financial advisors. When the solution is ready for coding, one could easily set up a simple front end with chart components and code back end that opens, writes, reads and calculates the values from an excel file before it’s translated into code.

    Tools to speed up delivery

    There is a plethora of software plugins, DLLs, open source projects and code snippets available that can assist in speeding up delivery.

    It’s worth doing a quick check for open source solutions available that could be used as a base for the MVP.

    Here are some ideas to get a project off the ground:

    • Base software – WordPress, DNN, open source CRMs and built in framework functionality (e.g. .NET Identity for authentication) can speed up a project to get it off the ground faster.
    • Front end plugins, libraries and frameworks – Jquery, Angular, Bootstrap, datatables.net and Telerik could also assist in meeting requirements for lean testing.
    • Dev-ops – Continuous integration tools (TeamCity, Jenkins), Continuous deployment (Octopus) and logging services (ElasitcSearch or appcenter.ms for mobile apps)
    • Cloud solutions such as Azure and AWS offers many services, functionality and APIs to speed up development

    Conclusion

    For many startups, the focus is on getting to market as soon as possible. They do not always have the time to wait six months for bespoke development.

    Rapid application development tools can assist developers in getting a customer’s product to market as soon as possible.

    Though one needs to weigh up the impact this might have in the long run, once the company’s cash flow is there, more enhancements can be added to the list.

    Simply be effective.

    Sources consulted

  • The Effectify Way – Planning your software development project

    The Effectify Way – Planning your software development project

    Effectivity through good processes

    Every day many employees and businesses use complexity as a way to hide issues and unprofitability. .

    One should never be dazzled by complexity.

    The Effectify way is, as the name suggests taken from the Toyota way. It’s about optimising the process and simplifying what we have to have better performance and make something more usable.

    Our approach

    The SDLC and problem solving

    Though the software development life cycle is cyclical, it very often happens that the clients prefer to hand over the maintenance of the solution to their own team or hire their own software developer to maintain it.

    For this reason, the process below is linear.

    The Effectify Way focuses on solving customer issues.

    Once a problem is defined, it’s only a matter of time until it is resolved.

    As it’s important to find, define and solve the problems long before the coding starts, the focus is placed on research and understanding the problems involved.

    What if the uncertainty is too great?

    In certain scenarios, a problem cannot be defined as easily as the above. For example, a startup functions under extreme uncertainty.

    Though many problems can be solved, one needs to solve only relevant problems. This needs to happen in bite-sized chunks.

    As the answer to the current problem could determine the next question/problem to solve, it makes sense that a linear approach would be unproductive. A cyclical approach would be appropriate for businesses that have a high level of uncertainty.

    Each iteration identifies the next question that needs to be asked. Once the question is identified, one can execute a test to receive the next answer.

    Should my project be linear or cyclical?

    Depending on the client needs, either one of the two approaches can be used.

    To avoid the deadly spiral of over-engineering, it is wise to use certainty as the gauge for the decision.

    Once the diagnostic phase has been completed, the appropriate approach would surface.

    The diagnostic phase

    Before any coding or work starts, we prefer doing a diagnostic phase.

    It’s important that we understand the problem that we need to solve.

    For example, a client is looking for API integration with all the major phone networks. He hasn’t inquired yet about existing APIs and current functionality. If this is part of the core functionality, this dependency could determine the success of the project. It would be irresponsible to give time and monetary estimates unless this has been unpacked.

    It’s definitely not ideal to start a project and halfway into the project it is discovered that the timeline moves out with 6 months, or that the vital integrations do not exist.

    Research and planning

    Once the diagnostic phase has been completed, one is able to give timelines and cost estimates for the work that needs to get done.

    Once the research and planning phase has been completed, a research document – a business requirement specification (BRS) will be delivered to the client. This is very similar to a business requirement specification, and developers can use this as a base for the coding that needs to be done.

    In the diagnostic phase, the technical aspects such as API integration, third party requirements and the appropriate platform has been fleshed out. In the research and planning phase, the appropriate system and code architecture needs to be considered.

    The research and planning toolbox

    Technical and code approaches
    • Appropriate technology choices
    • Architecture choices
    User Experience
    • Personas
    • Needs analysis
    • Process flows
    • User stories
    User Interfaces
    • Corporate identity and branding
    • Low fidelity mock-ups
    • High fidelity mock-ups
    • Icons

    In the research and planning phase, the user experience research and user interfaces are also included.

    To understand the user better, the Effectify way does a needs analysis (which could take the form of interviews, data tracking and collection of relevant information). From the information gathered, personas are created, followed by process flows and user stories.

    Execution – coding the solution

    Once the blueprint is in place, the execution can start. The blueprint will dictate the following:

    • the technology used – including coding framework, language and architecture
    • the platform (mobile, web, desktop application, cloud, etc)
    • third party integrations and external technologies leveraged

    We believe in a UI first approach to get more client feedback earlier in the software development lifecycle. If one can see how a solution will look and navigate, the code logic can be set up accordingly.

    It’s also important to supply weekly updates so that no one is out of the loop about where the project is and where it’s heading.

    Testing and feedback

    It’s worth noting that any company that claims that they write bug-free code needs to be avoided. As humans are involved, bugs are bound to creep in. For this reason, the Effectify Way avoids the ‘big reveal’ at all costs and does small incremental releases so that testing starts early in the process.

    Though unit test coverage for code is vital for code stability and trust, it’s also important to do negative and functional testing.

    Conclusion

    The Effectify Way is about simplifying processes.

    When someone uses software written by a developer, it needs to work.

    More importantly it needs to be used – it needs to be relevant, easy to use and viable.

    Simply put, it needs to be effective.