How we helped a startup build an innovative supply chain visibility platform

The need for efficient and automated supply chain processes is critical. Yet there is no single system available in the market that can give companies visibility on the state of the supply chain and manage the myriad of tasks related to running a smooth operation. Most companies use a combination of software tools, ERPs, emails, and spreadsheets to achieve this critical goal. For companies striving to stay ahead in their respective industries, embracing cutting-edge software solutions is not just a choice; it's a necessity. This is the need that a NY-based startup P1ston saw and decided to change things. The problem they had was to, find on short notice and on a very tight budget, a software team that would build their platform. This is where we came in. Kaz Software has been helping companies like P1ston for the past two decades build out their products. P1ston’s ambitious plan of building an MVP fast and then iterating to build out the full product in a very short time was challenging. And the type of challenge that we loved!

In this post, we'll explore how our experience in developing a supply chain automation platform for P1ston, Inc. serves as a testament to our capabilities in helping companies build robust and tailored software solutions.

Understanding the Need:

The journey begins with recognizing the unique challenges faced by companies in their supply chain operations. In the case of P1ston, Inc., it was the absence of a cost-effective platform for small- to medium-sized manufacturers and distributors. The lack of visibility into open order processes led to production shortages, lower on-time delivery (OTD), and significant inefficiencies. The first step in helping companies build their software is a deep understanding of their pain points and aspirations.

Crafting Tailored Solutions:

Our approach involves crafting tailored solutions that address the specific needs of each client. For P1ston, we developed a multi-tenant Software as a Service (SaaS) platform that provides supply chain visibility and workflow automation. This platform allows both buyers and suppliers to have real-time access to crucial information about their purchase orders. The incorporation of an open API and pre-integrations with popular ERPs ensures seamless communication with existing systems, making supply chain operations scalable and efficient.

Technology Stack for Success:

Choosing the right technology stack is crucial for the success of any software development project. In the case of the P1ston platform, we leveraged .NET Core, node.js, and React on AWS with a serverless and microservices architecture. This powerful combination not only ensures flexibility and scalability but also lays the foundation for future enhancements. Companies looking to build their software can benefit from our expertise in selecting the most suitable technologies for their specific requirements.

Collaborative Partnership:

Our success is not just about writing code; it's about building collaborative partnerships. P1ston, Inc. was an innovative startup with a vision to reinvent an established yet inefficient sector. To meet their rapid scaling needs, we assembled a dynamic engineering team capable of quick adaptation and implementation. The partnership was built on a foundation of shared goals, open communication, and a commitment to delivering results in record time.

Driving Efficiency and Lowering Costs:

The P1ston platform has empowered manufacturers and distributors to communicate faster, streamline sourcing efforts, stay informed, and exercise better control over their supply chain. The results speak for themselves - lowered costs, increased efficiency, and a streamlined workflow. For companies aspiring to build software solutions that drive similar efficiency gains, our experience with P1ston serves as a blueprint for success.

Looking Ahead:

As we reflect on our journey with P1ston, Inc., we are reminded that every software development project is an opportunity to make a lasting impact. Our commitment to innovation, collaboration, and understanding the unique needs of our clients positions us as the ideal partner for companies seeking to build software solutions that transform their operations.

In the ever-evolving landscape of supply chain automation, the key to success lies in visionary solutions and collaborative partnerships. Our journey with P1ston, Inc. exemplifies how companies can leverage our expertise to build software that not only meets their current needs but also sets the stage for future growth and efficiency gains. If you're ready to embark on a transformative journey for your business, let's build the future together.

Check out the transformative P1ston platform at www.p1ston.com

Why should you use an agency to build your software?

In today's fast-paced and highly competitive business environment, companies need to continuously improve their operations and processes to stay ahead. One way to do this is by leveraging technology and software to automate and streamline various functions. However, not all businesses have the in-house expertise or resources to develop and maintain software solutions on their own. This is where software development agencies come in - they offer a range of services to help businesses create, implement and maintain software solutions that meet their specific needs. In this blog, we will discuss the benefits of using a software development agency.

Cost-effective

One of the biggest advantages of using a software development agency is cost savings. Hiring and training an in-house team of software developers can be costly, time-consuming, and risky. By outsourcing software development to an agency, businesses can save on salaries, benefits, training, and infrastructure costs. Surveys show the cost-effectiveness of using an agency in low cost software destinations such as Bangladesh but even if you are not going offshore using an agency close to you will bring down your costs by reducing your HR commitments along with the cost of operation.

Expertise and Experience

Software development agencies have a team of experts who have extensive experience in developing software solutions for different industries and use cases. They have worked on various projects and have the necessary skills, knowledge, and tools to create effective solutions quickly and efficiently. They also keep up-to-date with the latest trends and technologies in the industry, so businesses can benefit from the latest innovations and advancements. By hiring an agency in essence you are getting access to their entire skillset and expertise on a need basis, a great example is how we help our software customers with a design team when they need to create visualization of their ideas - the design team comes in for a short time to turn the ideas into mockups and specifications that the software team can use as their guide. The cost to the clients is minimal, yet the benefit is a dedicated design and product team that only giant companies can afford.

Faster Time to Market

Software development agencies have streamlined processes and workflows that enable them to develop and deploy software solutions faster than an in-house team. They have experience working on different projects and can quickly adapt to changing requirements and timelines. This means businesses can launch their products or services faster and gain a competitive advantage.

Scalability

A software development agency can scale its resources and expertise based on a business's needs. This means that as a business grows, the agency can provide additional resources and support to meet the increasing demands for software development services. Similarly, if a business needs to downsize or reduce its software development needs, the agency can adjust its resources accordingly.

Focus on Core Competencies

By outsourcing software development to an agency, businesses can focus on their core competencies and strategic initiatives. This means that they can allocate their resources and attention to activities that are critical to their success, such as product development, marketing, sales, and customer service. Software development becomes a supporting function rather than a core competency.

Using a software development agency has many benefits for businesses looking to develop custom software solutions. It can help businesses save on costs, access expertise and experience, launch products faster, scale resources as needed, and focus on core competencies. Businesses should carefully evaluate their software development needs and choose an agency that can meet their requirements, deliver high-quality solutions, and provide ongoing support and maintenance. By doing so, they can reap the benefits of technology and stay ahead of the competition.

Software: it's not for you, it's for your customer

The Crucial Art of Understanding Your Customer

In the dynamic landscape of software product development, there's a cardinal rule that often separates the triumphs from the tribulations: understanding your customer. The adage, "Your software is not for you, but for your customers," echoes through the corridors of startup wisdom, serving as a guiding principle for those seeking to navigate the complexities of bringing a digital creation to life.

The Costly Mistake of Losing Sight

Whether you're steering the ship as a startup founder or collaborating within a seasoned product team, losing sight of the end user's needs can prove fatal. It's akin to embarking on a journey without a map; the chances of reaching your destination diminish with each step taken in the dark.

Market Research: Illuminating the Path

Diving headfirst into comprehensive market research is the first beacon of light in this journey. It involves not just studying market trends but engaging directly with potential users. Understand their pain points, desires, and expectations. What keeps them up at night, and what would make their lives easier? These are the questions that form the basis of a foundation strong enough to withstand the tests of time.

Embracing Feedback: The True North

Feedback is the lifeblood of progress. Yet, many developers and founders shy away from it, fearing criticism or divergence from their original vision. This hesitancy is where the downfall begins. Embrace feedback, even the harshest critiques, as they are the keys to unlocking a product's true potential. Users, after all, are the most authentic judges of a product's usability and relevance.

Recognizing and Overcoming Biases

In the quest to create groundbreaking software, acknowledging and overcoming biases is paramount. As creators, we bring our own experiences, preferences, and assumptions to the table. However, these might not always align with the diverse needs of the target audience.

User-Centric Design: A Paradigm Shift

User-centric design is more than just a buzzword; it's a paradigm shift in approach. It involves stepping into the shoes of the end user, understanding their context, and designing a product that seamlessly integrates into their world. This shift challenges preconceived notions and ensures that the final product isn't a reflection of the creator's preferences but a solution tailored to the users' real-world challenges.

Personas: Bringing Users to Life

Creating user personas is a powerful technique to personify the abstract concept of your "customer." It goes beyond demographics, delving into the motivations, frustrations, and aspirations of fictional characters who represent your target audience. By crafting these personas, you build empathy and gain insights that can shape a product into something users don't just need but truly want.

The Process: Tried and Tested

As the saying goes, "To know thy customer is to know thyself." The journey of understanding your customer isn't a linear path but a mosaic of interconnected steps. Here are some key stepping stones:

1. Conduct User Interviews: Schedule one-on-one interviews with potential users. Listen actively, ask probing questions, and seek to understand the intricacies of their daily lives.

2. Utilize Surveys: Surveys are a scalable way to gather information. Craft well-thought-out surveys that touch on pain points, preferences, and user expectations.

3. Iterate Based on Feedback: Your product is not a static entity but an evolving one. Be prepared to iterate based on user feedback. Every critique is a valuable opportunity for improvement.

4. Test Prototypes: Before the full product launch, test prototypes with a select group of users. This provides real-world insights without the risks associated with a wide-scale release.

5. Leverage Analytics: Once your product is in the hands of users, leverage analytics tools to track user behavior. What features are popular? Where do users drop off? Use this data to refine and optimize.

A Warning Against Complacency

The ever-changing landscape of technology demands perpetual adaptability. Understanding your customer isn't a one-time task but an ongoing commitment. As markets evolve and user expectations shift, staying attuned to your customers ensures that your product remains relevant and impactful.

In the symphony of software product development, understanding your customer is the melodic refrain that resonates through every stage. It harmonizes market research, feedback, and user-centric design into a composition that strikes a chord with users. Embrace this cardinal rule, and your venture will not only survive but thrive in the dynamic and competitive realm of software innovation. After all, success in software development is not just about lines of code; it's about understanding the hearts and minds of those for whom the code is written.

Managing a multi-cultural remote software team

Remote work is the new normal, and managers need to be prepared to lead their teams in this new environment. And in today's globalized world, multicultural teams are the common remote teams. Cultural diversity is common in onsite teams too but the issues of miscommunications because of cultural issues are much more complex in remote teams. With the rise of remote work and the desire for flexibility among younger generations, managing a team from different cultural backgrounds has become one of the biggest challenge for managers. And this is an essential skill that all managers are picking up.

Since Kaz is a software development agency based out of Bangladesh and we work mostly with software companies based in the US or Europe. So the very nature of our work leads us to the remote cross cultural issues. And this not a new thing for us because of the recent rise of remote work. We’ve been participating in remote software teams for the past 18 years, and over that long time we’ve probably seen all the things that can go wrong in such cross culture, cross language teams and have devised strategies that solve those issue (or at least reduces to chances of them arising). We’ve also come up with a little poster for expressions in English that doesn’t translate well, that we sometimes give to our customers’ project managers as a cheat-sheet! So, today’s post is a summary of some of our best tips around this and that useful “cross culture expressions to avoid cheat-sheet”.

Understand that there is problem

This is important. Specially in the software world. We sometimes hear things like: “At the end it’s all code, and the language of code is the same so there will be no problem”. Although at the fundamental level that is very true, but to get to that stage of work and collaboration the remote teams still have go through layers of communications. That communications is typically in a language that isn’t a first language for at least one side and sometimes for both sides. And that’s where the start of the problem happens, and layer on top of that the cultural difference and the fact that cultural context changes the meaning of many expressions and mannerisms - you have a problem. So it’s vital for software managers to understand that there is a problem and it will need active strategies and process to solve that problem.

In this context, it is essential to recognize that cultural differences can lead to misunderstandings and conflicts. As the speaker in the video explains, even seemingly simple things like expressions about time can have very different meanings in different cultures. For example, in some cultures, "just now" might mean "in a few minutes," while in others, it might mean "sometime in the future." Without understanding these differences, miscommunications can easily arise, leading to frustration and conflict.

Create culture awareness in the team

To address this challenge of cultural difference and the need to work around such difference, it is important to invest in cultural awareness and sensitivity training for managers and employees. This might involve providing resources such as books or online courses on cross-cultural communication, as the speaker in the video did. It might also involve hosting workshops or training sessions led by experts in intercultural communication.

One key aspect of this training should be the importance of context in communication. As the speaker explains, even when two teams are using the same language, differences in context can lead to misunderstandings. For example, a phrase that might be intended as a compliment in one culture might be interpreted as criticism in another culture. Understanding these differences requires a deep appreciation for the cultural norms and values that shape communication styles in different parts of the world.

Create an environment of trust

Another important aspect of managing a multicultural team is building trust and rapport among team members. When people come from different cultures, they may have different expectations about how to build relationships and establish trust. For example, in some cultures, it may be important to spend time getting to know someone on a personal level before discussing business matters, while in others, business may be the focus from the outset. Understanding these differences can help managers to build stronger relationships with team members and foster a sense of camaraderie and trust.

We’ve written extensively about this in the past, as we feel that this is one that that makes thing much simpler to solve cross cultural issues. Some of our tips can be found in this article about how to build trust in your remote team by team gelling or this one about creating the right team culture for companies with remote teams.

Find what works the best for you

It is important to recognize that managing a multicultural team is not a one-size-fits-all endeavor. Different cultures have different expectations around communication, hierarchy, and decision-making, among other things. Effective managers must be able to adapt to these differences and find ways to accommodate the needs and preferences of each team member. This might involve using different communication tools for different team members, or adjusting work schedules to accommodate different time zones.

Careful about what expressions you use

It's important to be aware that expressions that you might use in your language or cultural context might not be understood at all or even worse understood with the opposite meaning by your remote team. It is vital for team managers (and team members) to consider cultural differences when communicating with people from other backgrounds. It's also a good idea to clarify the meaning of an expression if you think it may be misunderstood. Here’s our list of common English expressions that just doesn’t cross the language and culture basriers well. We call it the expressions to avoid cheat-sheet!

"Break a leg" - This one never works. In most non-English cultures, wishing someone luck by saying "break a leg" is considered bad luck or even offensive. Actually if you think about it really weird that this expression has the meaning it has, here’s the Wikipedia post giving it’s history.

"Bite the bullet" - This expression means to endure a painful or difficult situation, but in some cultures, the literal meaning of biting a bullet can be confusing or offensive.

"Spill the beans" - This expression means to reveal a secret, but in some cultures, the idea of spilling beans may not make sense or may be seen as wasteful. I remember once one of our customers used this expression in the context of asking his team not to reveal software features anyone and the look of confusion in the team was very interesting!

"Piece of cake" - This expression means that something is easy, but it almost always fails to translate well.

"Going Dutch" - This expression means to split the bill, but in some cultures, the idea of going Dutch may be unfamiliar or seen as impolite.

"Skeletons in the closet" - This expression means to have secrets or embarrassing information, but to someone not used to the expression the idea of keeping skeletons in a closet would not make sense at all!

"Costs an arm and a leg" - This expression means that something is very expensive, but in some cultures, the idea of comparing something to body parts may be seen as distasteful.

"Cat got your tongue?" - This expression means to ask someone why they are not speaking or responding, but this one never works either for obvious reasons.

"Let the cat out of the bag" - This expression means to reveal a secret, but the idea of a cat being in a bag may not make sense or may be seen as cruel for non English speakers.

Common mistakes that new software companies make and how to avoid them

Starting a new software product can be a daunting task, especially if you are new to the world startups and software. While every new business journey is unique, there are some common mistakes that many founders make. After helping companies big and small - from Fortun500 beasts to one person startups, we think we’ve seen it all! In this blog today, we will discuss the some of common mistakes that we see over and over and also give some tips on how to avoid them.

Not knowing your customer

One of the biggest mistakes that software product leadership make is not knowing their customer. Notice I’ve kept the term very generic, “software product leadership”, and that’s because this mistake is made by startup founders as well as product teams in well established software outfits! It is important to have a clear understanding of who your target customer is and what their pain points are. This will help you develop a product or service that addresses their needs and provides value. Take the time to conduct market research and talk to potential customers to gather feedback and insights. Remember that the software you are making is not for you (well it may well be, but you are probably not its only user). So make sure your biases and fascinations don’t guide the software requirements. Find out out the real customers, find out their actual needs - their needs may not be at all like yours. We recently posted a detailed strategy of finding what features you should plan on your software - worth reading that too if you are considering this point. Also worth a read is another recent post about finding customers for a software product.

Not having transparent conversations with your co-founders

Co-founder relationships are critical to the success of any startup or a software product launch. It is important to have open and transparent conversations about roles, responsibilities, and goals. Without clear communication, resentment can build up, and the relationship can deteriorate. Make sure to have well-organized conversations that are designed to share how you feel about the current situation of the company, how it's organized, and who is responsible for what.

Not launching

Many startups are afraid to launch because they think they need to be fully ready before they can get in the press or be on popular blogs. However, launching is not as significant an event to your users as it is to you. If you think about it, how many famous platform do you remember being launched? We only find out about a new product once it starts getting traction - think Facebook, think LinkedIn and think if you ever heard them at launch time… most likely not! It is important to move up the launch as soon as possible to get your product in front of customers. This will help you validate whether it solves their problem and give you the feedback you need to improve. Remember the minimum viable product (MVP) way of doing things. With an MVP you move to a faster launch and a faster way to more feedback. A long time back we posted on our blog an article about how every software company should launch with an MVP and it’s one our most read articles.

Not using analytics

Measuring what your users do when they come to your site is critical to improving your product. It is important to track your website analytics and user behavior to understand what is being used and what is not. This will help you make data-driven decisions and prioritize features that are important to your customers.

Not prioritizing the actual product!

Startups often prioritize sizzle over the actual steak! I mean they make more fuss about various things around the product than the actual product itself, such as hiring, press, and conferences, over getting the product out there and talking to users. However, the actual work of startups is pushing product, getting it in the users' hands, and seeing if they like it. Prioritize getting your product in front of your customers, gathering feedback, and iterating on it to make improvements.

These are some of the most common mistakes that we see many companies make. While it is possible to be successful even if you make these mistakes, it is important to minimize them as much as possible to improve your odds of success. Good luck!


Finding great software developers

Your software business is growing. To keep pace with the upscaling, you need a great software team to handle all the tech things so that you can focus on your work of expansion. But, do you know how to find and hire that great software team? A team that shares the same vision as you?

It’s hard to find good developers, as their skills are so much in demand that unless you are Google or Facebook you’ll never attract top developers to build your software projects. Even if you find someone with great talent and skills that person may not be the right fit for you and your team: he might not understand your instructions well, or may collaborate well with the rest of your team. Yet it’s vitally important to get the fit right in software. Building a great software is all about a team working together.

So, how do find great software developers? Here are some tips from our experience in working with hundreds of companies around the world building their software products.

Know what roles you need to hire for

A software team is composed of many distinct roles. Each role is essential and together they move your project forward. Remove one and you’ll see that things aren’t moving as they should. A role doesn’t mean a single hire, many roles are one person but sometimes many persons also fill a single role. Let me give you some examples: you need a business analyst role, someone who would understand the business problem you are trying to solve, then also understand how the software will solve that problem and most importantly know what are the priorities within the solutions. You also need a product manager, who will know what the product is supposed to do, when a certain version should come out with what features to meet what business need. This product manager will be the coordinator who talks with the tech team communicating the need and scope and then understand the technical challenges that the team faces and then faces the business side to understand their needs and communicates what’s what’s possible and what’s not. Now these two roles - the business analyst and the product manager tends to be two very distinct role but if the project size is small or if you just can’t afford two separate resources it’s just about possible to mix them both an have one hire that takes on both the roles. And if small startup it could be the founder who takes that role along with other roles like business development and even sales.

Whatever the context, before you even think of searching for your team, have a list of software roles you need to fill up. Then do your maths and figure out how many hires can you do and see if you can spread out the list of roles within them. This will guide you to the next step of the skills you need in your hires.

Know what you want to make

You need to know clearly the what you are making and what your business priorities are during this making phase. You should all the main features of the platform, which features are the most valuable and which are good to haves and which you can do without. The technology platform should be a big factor in this, for example you should know clearly what you want to keep inhouse and what you can get an external agency to do for you. For example, you can outsource salesforce development and keep the rest in house. In a perfect world you should also have clear specifications and requirements documents before you start adding software developers in the team who would build those features - but that’s in a perfect world!

In a startup, the minimum viable product aka MVP holds the most importance before the product or service is launched. Creating a neat and efficient MVP increases the chance of the startup being successful as well as fund raising and beta testing. And, that is where the software development team becomes crucial. So if you a startup just going through the motions of making your first attempt at the software your needs for the team is very different from the situation where you are an established software company thinking of extending an already selling software.

Remember that having a clear view about what you are building will not only help you identify the skillset you need but also help you ask the right questions when you find potential candidates.

Reference, reference, reference

The tech world tends to be a very connected world. Personal advocacy is always a first choice for everyone when it comes to hiring people for a software project. In this case, you have to keep in mind that your product or service is based on, and according to that you have to find the right people with appropriate skills. Maybe a web developer has helped your friend greatly, but it will not come to handy if your product is based on android application.

Here at Kaz software, around 80% of our customers are referred to us by our existing clients and partners.


Searching on the internet

Searching at the right forums and discussion boards can land you rare skilled developers who are not available in other platforms. Many software development teams work as agency and offer their services through their own company. If you are willing to work with a readymade team who can start working for you, this is a really good option. Kaz Software is a good example of such sources of ready to start teams. We maintain skilled teams working in a wide range of technologies from web application to mobile apps. The added benefit of using a company like ours is that we come with resources that a software project needs time to time but not always - resources like technical writers, designers, testers and systems support. And you can take help from such resources on a need basis, greatly reducing your HR spend and managing your budgeting.

Online platforms for freelancers like UpWork or Fiverr are widely used by employers who want to hire a remote resources. These platforms tend to be good for smaller or one off type projects. However, you can find freelancer groups as well who work together to offer service to startup owners to build solutions. The services can be web or app development to custom CRM solutions. This can be a really effective solution if you’re running low on budget. Also, you can find freelancers while knowing their actual review and rates. 


Social media and LinkedIn also can be a great option if you want to know the detailed and previous portfolio of employees. The experienced ones post their portfolios there, specify their skills, and the level of their endorsements shows their overall efficiency at their job. Even they don’t match your preferences, you can always connect with them and other people to get more people’s profile. Start by searching for the keywords relevant to your requirements and get the list of potential employees. Browse through the results, assess the profiles and send a proposal to them.

Offline search

You can always go search for technical people in person in events. A lots of conferences, meetups and hackathons take places regularly where you can find the right person to work with and discuss your work briefly. Especially in hackathon, you can get to see the efficiency of any individual or team who are just an event away!

Remote Resources

You don’t always need your team to be situated in the same spot. The entire world can really be your source of software hires! Remote software development teams can easily be managed using collaboration tools like Slack, Zoom, Jira, etc.

Remote software teams should only be hired through reputable software companies as they provide infrastructure for managing those resources, provide the right working environment, run the payroll, manage their holidays and work hours, etc. The most crucial reason for hiring remote teams from established software companies is the things around a team that makes a team coalesce and work with motivation. These include great office spaces, network and systems support, team activities and team building events. All of these keep technical staff motivated and companies benefit from that motivation.

Recruiters and managed service providers


Last but not least, if you want to outsource the hiring work to save your time, you can work with a recruiting agency or with a MSP aka Managed Services Provider companies who are mainly specialized in technology recruitment. This is a path we don’t suggest to our clients unless they are really short on time or are desperate for resources they cannot find in any other way. The main reason for putting this as a last resort is the difficulty of finding the recruitment agency that really understands your needs properly. Usually these agencies are working off a generic keyword driven hiring agenda that is not always the perfect fit for your actual need.


Making you software dreams come true

Now is the time

It's never been easier than now to actually develop and release your first piece of software. You can do it in spare time after work or on the weekends so you don't have to wait and delay it anymore. The technology exists to help you move things faster. The only thing that is holding you back is your fear.

 You are not alone in this. There are many people with similar fears - some of them are even afraid to post their ideas on the web because they think someone will steal it. But this just doesn’t make sense, we know first hand how hard it really is to make something good and useful so the huge moat that exists from idea to a real usable software is huge. Ideas are easy, it's the execution that is super difficult. I will argue in this post that now is the time to start - you can start with something and end up with a very different product and a different company. Remember you can always run a rebranding of the company once you know exactly what works. Here’s how you should start.

Take the first step

We all have dreams about making something useful, something that solves a pain, something that makes our life that much easier. That is exactly how all the software platforms around us started. It's very easy to forget that when you are in the middle of the whole thing. But it only takes a bit of research to uncover all the stories behind today's giants. And these people weren't billionaires sitting on their money before they made their products, they were just like us, with big dreams and nothing to lose. Sure there was some hiccups, maybe huge ones, but every little mistake is just another signal for you to change your idea so that it fits with what the market needs.


Start deciding now what is it that you want to make and start doing some research about what the market needs. This way you will make sure you are not wasting your time and energy on something that has already been done or that can't be done properly because there is no demand for it. Of course the last point raises the question: How do we find new ideas? How do we know that the software I'm planning will be something that everyone wants?

What do people really want?

Sometimes it is easier to find a gap in the market. This simply means that you research what your competitors have and try to analyze what they are missing or not doing properly so that you can offer the same product with more advantages. For example, there were a lot of applications for office tasks but no one offered a solution for lunch at the office easily! And that's the niche that all the food delivery platforms filled in. Food delivery disruptors like just eat or uber eats are just ideas that came by finding the gaps in our everyday life's workflows. Take this from the wikipedia article about one of the oldest food delivery apps: :Takeaway.com was created by Jitse Groen in 2000 after he had a difficult time ordering food online from local restaurants. Initially, Groen wanted to deliver all kinds of consumer goods; however, he noticed that food deliveries had the most demand, and decided to make this the company's primary focus. This is a common story for most successful apps.

Another way is to think of something that you just hate with a passion and then come up with a solution. If you have an idea, don't wait for it to be perfect - put in the time and effort right now! Chances are likely that there are many others who share this dissatisfaction with what currently exists so your product will probably find some fans. That's all you need to keep the ball rolling - some early adopters. They will give you the ideas of what else is needed to make it even more useful. What features people will pay for, what they lack in the market. Starting from a small set features leads you to take the baby steps that lead to software that people really want. Take any successful software as an example, look up their history and you'll find that they all started with a very very small set of features and they changed, updated and upgraded all the way. Do you remember how MS Word 1.0 was? It was a disaster, a buggy software that had much less features than the leader in the field then Word Star or Word Perfect. But what MS Word did was solve the pain of remembering formatting codes and use the wsywig paradigm to make users' life easy. It wasn't perfect, but it was a start.

Software is difficult. It requires dedication, creativity and endurance to make it happen. You will have to conjure up the programming language that fits your needs, come up with features for your software, make sure everything works across devices, platforms and operating systems. But if you are now finally ready to face all these challenges - welcome!


Making your software: Step 4 - Budgets and funds

Making you software (1).png

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. In step 2 she went over strategies to find a software developer company who will turn her dream into reality. Then she gets good ball park estimates for making the software in step 3. Now that she has some numbers she can work on her next challenge of budgeting and financial planning for the software development.

Software development can be expensive, so a proper budgeting and financial planning is essential to make your software and launch it successfully.



Phases of software launch

There are several distinct phases in getting a software product to the market. These phases actually go way beyond the obvious software development and sometimes the founders don’t really realize all the steps and runs into difficulties with finances when that step happens. Here are some of the phases and what a founder should expect from a budgeting and finance point of view on such phases.

Design and planning

Every software product has a significant design and planning phase. If you cut this phase short you end up a poorly designed software that is hard to use or a software that took a lot more time and money to build because the developers just didn’t have enough guidance on what to make. So it’s essential to invest on the design phase. If money is tight, as it is on most startups, this phase can be less elaborate than what textbooks suggest about design and planning of software but it still needs to have some basic things done. The top focus should be a set of “mockups” of the software interfaces. These are pictures of the software screens as the user goes over common or most used features. If money is seriously short, these mockups can be just black & white rough sketches called wireframes, but that’s the bare minimum that must be done.

Typically this phase will require 10 - 15% of your total budget for the software.

Development of the MVP

This phase is the actual software building phase. MVP stands for minimum viable product and we’ll go over the concept of MVP in a separate post. But basic idea is simple: find out what is the minimum set of features that will sell the software and make that first and launch with it. Here’s good video about MVP..

Typically as founder should plan for 40 - 50% of her total initial budget for the MVP.

Launch and marketing

The launch of the product by itself is time consuming and can come with unexpected costs. The developers may request for server certificates, special cloud setups, software licenses that a founder may not have budgeted for. On top of that the launch process itself takes developer time which adds to the costs.

The marketing is obviously a huge area to think about when you are launching a product. Nothing sells without proper marketing.

Typically launch and marketing should be around 20-30% of total initial budgeting, but note that this is one area where it’s very product specific. If a software is planned to be something based on a huge number of users then marketing itself can take up more than half of the all the money spent in a project.

Releasing the updates

The biggest mistake that founders make is not factoring in the costs of making changes to the software AFTER the launch. These changes are usually the make or break between a software that people use and one that goes into the software graveyard. After all, only after a launch does a founder really get to see what works and what doesn’t, what her users are using and what they are asking for. Based on these real data points a founder has to adapt the software, modify it or fix the bugs to quickly launch a new version (usually a series of new versions) that adapts to the need of the market. This process is iterative, it’s usually time and effort consuming and thus it’s expensive. Not budgeting for this phase means the software never had a chance to fight it out in the market. So it’s absolutely essential.

Typically a founder should budget at least 15-20% of her initial funds for this phase.

Maintenance

Maintenance is the phase of managing to keep the software live over time. This may involve bug fixes time to time, maintaining the servers, updating various components as new versions of the OS or other software is released or new security patches are put out. For mobile apps this means the continuous effort to keep up with the new versions of OS that Apple or Android guys are coming up with, each having the potential to break your software.

A founder should budget for at least 2 years of maintenance after launch in her initial planning. Very much a product specific thing, but typically over 2 years it would take up 15 - 20% of the overall costs.

Payment strategies

When the founder is planning for financials of a project there are certain strategies she can adopt for the funding and the payment to the developers. These are general tips, after all, as each project is different with it’s own sources of funding, own specific situations of payments. Here are two strategies that works well for startups.

Milestone based payments

Setting up a payment schedule with the developer based timed milestones is great for both sides. For the founder it gives certain dates where she needs to make the money available, it also gives are a quantifiable way of seeing what she is getting before she does the payments and of course more solid commitment from the developers about the dates. For the developers it’s a good way of splitting up a bigger software project and getting paid as they build it. It reduces their risk by not lumping everything up for a big payment at the end.

Phased development

The phased development strategy is where the founder just makes her final product over a set of phases. Each phase has it’s own launch, marketing and payment. This way the founder can get the product out in smaller steps, judge the market as she goes along and only commit to more payments if she sees the demand. For a developer too it’s is a good way of splitting a large project up and getting paid early. But note that if the phases are too small this might be impractical for the founder and the developer as the costs of starting and stopping the project in each phase can be a big overhead.

OK, that’s it for today on this series on getting your software made. I’ll be back soon on step 5 soon about finalizing a software partner to get software made.


Top Benefits of Hiring an Offshore Software Development Company

#1 tip for software developers (72).jpg

There’s a constant uptick in security breaches of companies around the world. It’s a never-ending concern for security professionals, especially since countless organizations are not giving it much attention.

A study by IBM Security/Ponemon Institute conducted in 2019 concluded that the average cost of a data breach is $3.92 million. This raises an important question, "What can companies do to safeguard themselves from these attacks and potential losses?"

How do software vulnerabilities affect businesses?

Software vulnerabilities are flaws or weaknesses in software that compromise the security of a company’s system. These issues can be critical for businesses as a data breach or system attack can easily cost millions of dollars in compromised files, operational challenges, and system maintenance.

How to prevent security vulnerabilities

Data breaches show no signs of letting up; therefore, having secure software is vital to every organization. Although not all attacks can be fully anticipated, many can still be avoided by following the tips below.

Define Security Requirements

You must ensure that security requirements are clearly identified and observed during the entire software development life cycle. This includes business objectives, company policies, risk management programs, and applicable laws and regulations.

Be Mindful of Third-Party Software

Minimize the risks of being exposed to vulnerabilities by managing the use of unsafe third-party components. If using third-party software is inevitable, only use those with Code Signing Certificates to guarantee its authenticity, effectiveness, and trustworthiness.

Consistently Identify Vulnerabilities

Limit an attacker’s window of opportunity by regularly checking your systems for vulnerabilities. Assess and test the software's code to identify new risks. Establish an efficient response program to ensure security researchers can log weaknesses as soon as possible. 

Get Help from the Experts

Since developing innovative, functional, and secure software is what software development companies focus on, they have a strict and consistent process and guideline that they follow for every execution. In a nutshell, they’re the experts who can effectively help your company with your infrastructure.

Why hire an offshore software development company?

To help businesses decide how software development vendors can help with their system security, we’ve broken down the top benefits of hiring an offshore software development company.

Guaranteed Security

Trusted software development vendors are experts in their industry, especially with system security. They are knowledgeable about the dangers that companies can face and how to mitigate them. Partnering with the right firm means you’ll have access to professionals that would turn your business and security requirements into a reliable product.

Cost-Saving

Outsourcing your development project is a more efficient and financially sound choice since you won’t have to hire and train an entire team to create software. You can use the money you save for the betterment of your company.

Reduced Liabilities

A software development process requires a lot of valuable time and resources. It demands full attention on the core objective, from the inception phase to the deployment of the solution. 

To maintain the project, you must have a dedicated team to handle the task and acquire the tools for development. These obligations can be expensive for companies, especially for small and medium-sized businesses trying to minimize liabilities while maximizing the efficiency of available resources.

Faster Development Time

Competition is tight in today’s market, so producing secure and functional software in a short time will benefit a company. In-house development requires hiring software developers and researching rigorously on the best tools needed. Without the technical know-how, this can take a lot of time and delay the entire process and compromise quality.

Utilize The Top Resources And Technologies

The technology landscape is rapidly evolving, with technologies such as artificial intelligence, blockchain, natural language processing, and many more changing how industries operate. Different resources are being utilized in offshore development, which enhances the development life cycle and their ability to create powerful software that influences innovative technologies.

Offshore development offers a simpler course to expanding your business and leveraging the decade’s technological advancements. Not to mention the security and peace of mind that it can offer your company. Ensure seamless business continuity and growth with these insights.


Freemium model for software sales

Monetization of a software product is key focus for any software company. The big question is “how?”. Gone are the days when you could make a software, burn it into a CD and sell the CD for a price - making the intangible tangible. It was great while it lasted, as it was an easy concept to comprehend, consumers are used to buying a product that they can hold or touch. A CD would give them that feel and then installing the software just felt like part of setting up the tangible product. In the mental model of consumers the CD was the product.

CDs don’t make sense anymore. Even downloads and installs are outdated. Consumers expect software to be online and ready to go and worst of all “free”. Can you imagine paying for a basic email service? The likes of gmail, yahoo and hotmail has destroyed the concept that you have to pay for a thing like an email. So the direct “here is your product give me the money” days are out. What’s come in are new and innovative ways of selling software services. Freemium is one such model that has gained grounds as the main model these days for monetizing software products.

What is Freemium?

Freemium model is a process where users get basic features of a software for free and can access special or upgraded features for a subscription fee. The “FREE” part attracts users to the software, so it is essentially a marketing spend for the software company and the “premium” part of the freemium word is the part that actually gets the software company the money. Most of the services around us are essentially one form or another of freemium e.g. networking with LinkedIn, shared files through Dropbox even emailing with gmail are all freemium models in action. “Gmail?” you say, that’s not freemium, but it is. As soon as you reach their limit on storage (which I promise you will reach one day) you get this:

gmail asking for money.png

Which eventually lead you to this:

gmail asking for money 2.png


Why Freemium?

Several things make freemium the perfect model for selling software. Free features are a powerful marketing tool, essentially an immersive advertisement for your software that draws customers in. The model is great because it allows a new software company to scale up and attract a user base without using resources on costly ad campaigns or a traditional sales force. Under a freemium, a software gives away a service, that obviously costs money for a company, at no cost to the consumer as a way to establish the foundation for future payments. So in essence it can be thought of as deferred payment. By offering basic-level services for free, companies build relationships with customers, eventually ensuring payment from them for advanced services, add-ons, enhanced storage or usage limits, or an ad-free user experience. It’s a great win-win. Companies win because they can get customers onboard easily without huge marketing spend, and customers win because they get to use the software before buying.


Does it work?

Definitely. That’s the sole reason for it’s wide adoption. If you want to look at results do a search on google and you’ll probably find a thousand sites that prove that it’s a working business model. Dropbox is a great example. When it launched, in 2008, it was mainly a service for backing up files. It then began offering shared folders, making it a collaboration tool. Newer features allow for automatic syncing of smartphones and other devices and for automatic uploading of photos. Over time the user interface has improved as well. Each new feature has increased the value of the premium offering. And in their 2018 filing they showed that they had more than 500 million free users and they were earning more than $1 billion in revenue!

As consumers ourselves we would also agree that freemium is a great model for software. It lets us explore a software without making financial commitments right away. It let’s us compare multiple services and select the best one. So if you are thinking of software monetization think of the freemium model before you consider anything else.

6adbd12c7acec88be9dba7cb37fffab9--business-models.jpg



Making your software: Step 3 - Ball Park Estimates

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. She has then gone through the methodical approach of finding possible software developers using a simple yet effective process using the method laid out in step 2 - find software developer She now has a shortlisted software developers who are likely to be a good fit in terms of skills, capability and communication. Now is the big question of money,

“How much will it cost?”

But costing a software development project is not as simple as just saying oh these are the materials, this is how much it will be. That is because there are a multitude of unknowns in a software project. If you take Priya’s situation you’ll know what I mean. She only has an idea of software and some features. Roughly she is looking for a software that will:

Making you software.png

a) Let users try out interior design in their room.

b) Take pictures of those designs and ask for feedback from friends and family.

But is that all? If you dig even a little bit further a hundred new features starts coming up that are essential. For example:

c) users will need registration, password management, trial access, etc.

d) there will be a need for a payments

e) priya will need administration interface for managing her users and also for stats.

f) ….

And we haven’t really even scratched the surface yet. For example, how does a user do the first feature of trying out interior design? Will there be little furniture pictures that users will be able to arrange? Will the user have ability to change colors of the walls and furniture? Will there be a library of furniture pictures? …

Each of these questions and their answers lead to features and work which leads to change in the cost. The actual requirement analysis is by itself a big part of the software development work and it takes time and effort to do. So for any sane software company it just doesn’t make sense to go through the whole process without getting paid or without some assurance of getting the full project. But on the other side Priya needs to have at least a rough idea about the costing of the project - will it be a few thousand or a few hundred thousand? And the answer to this predicament is

The ballpark estimate

An estimate that can be wrong in the actual number when all the requirement is done and dusted but which is at least in the same order of magnitude. So it’s like a software developer saying “hey, Priya, your software will cost something around 50K” and the actual final cost might be 80K, but it wouldn’t be 500K for example.

For any software company with experience and skill, coming up with a ball park is relatively easy. It will probably require some effort - maybe a day or two (and even a week) of going over what’s known and trying to guess the effort. But it’s far better than spending weeks on scoping and estimation work without knowing for sure if the project will be awarded to them or not.

So most software companies are OK in the little investment of coming up with a ball park number.

The art of estimating the ballpark number

Ballpark numbers are very rough cost estimates based on the specification you give to the developers. This number helps you figure out costs and plan your funds. To get a reliable ballpark you’ll need to spend some time with the developer to go through your concept, answer their questions etc. And obviously you can only do that with only a few.

Most software companies will guide you through the ballpark estimation process by asking questions. But from your side you need to take some action too to make sure that the right questions are asked and that certain concepts are clear to the software developers. Here’s our list questions that we make sure we ask and clarify:


  • What is the closest thing like your software currently available? Can you give us a link?

  • Do you have any preference on colors and themes? Can you give us an example site/app?

  • Where do you expect your users to use the software the most - on their browsers or their mobile devices?

  • Do you want a mobile app too? If so do you want them on both iOS and Android? Why?

  • Tell us in your own words how your users will use the software.

  • Tell us in your own words how you expect to manage the software, users, accounting, etc.

  • Tell us about your potential users. Would your users be computer savvy? Would they have good internet connections? Would they have good devices?

  • What would be the language preference of your users? Do you expect your software to be multi-lingual?

  • What’s your “drop dead” deadline? When do you need your software by to survive as a business?

  • If you were to choose just one feature, what would be that feature?

  • Going forward what is your expected cost of maintaining the software?

  • Who is going to maintain the software? What sort of skills does she have?


Living with bugs in released software products

Bugs are the reality of software. We hate them, we do everything we can to get rid of them but they are always there and we have to learn to live with them - that is we have to manage the bugs and fix them in a sane way. This is important. Actually trillion dollar important. in study done by the Austrian software testing firm Tricentis, software failures cost the worldwide economy over $1 trillion annually!

The same report also found that software failures have caused more than 315 years of lost time and have affected approximately 4.4 billion customers. Software failures also have a massive negative impact on the reputation of companies. The companies surveyed by Tricentis lost an average of $2.3 billion of shareholder value just on the first day after announcing a software failure. No wonder that so many companies keep quiet about bugs. Yet that is probably the biggest mistake. The trick is to learn live with the bugs as a reality and have a practical and realistic process for managing bugs in live products. Today’s post is an attempt to summarize some of the strategies we found as the best for managing bugs on live products.

Accept bugs

how to live with software bugs

This may sound obvious, but you’d be surprised how many companies treat bugs as something totally unacceptable and creates all kinds of penalties and punishments when bugs start surfacing on a product. This behavior comes from not understanding the nature of software products. Yes, the goal is always to have a bug free software release, but the reality is that there will always be some. So the goal should be:

“Release with as few deadly bugs as possible”

Accepting bugs opens up the possibility of a realistic software development process with healthy bug identification and resolution strategy. So this is the first step - for the management and for the technical team leadership.

Make finding and reporting bugs easy

Real life story:

A group of security researchers were prepping for a major reveal in 2013: They planned to disclose at a D.C. cybersecurity conference how a security flaw in luxury vehicles could let bad guys break in without keys and start the cars.

But Volkswagen stopped them, winning an injunction in a British court after arguing that publishing a paper detailing the problem would "allow someone, especially a sophisticated criminal gang with the right tools, to break the security and steal a car,"

https://www.theguardian.com/technology/2013/jul/26/scientist-banned-revealing-codes-cars

After you’ve accepted that there will always be bugs the released products your next sane thing is to setup a process and workflow for identifying and resolving bugs. It’s just crazy how many software companies out there try to hide their bugs or try their best to make it difficult for people to report them. There are literally hundreds of known cases where large companies tried to stop reporting bugs in their software - just making their users suffer even more.

This line of thinking is stupidity defined. You just cannot stop people from finding bugs. What you should do is make it easy for people to find them for you. Have easy ways for reporting such bugs - such as customer support emails that can easily turn into bug reports, a bug reporting page like Facebook’s Report a Bug feature.

On your development team’s side also have the tools for keeping track of all bugs that are being reported - both by customers and your QA teams. Tools such as Jira are absolutely essential, just as important as the software development tools or issue trackers when the actual software was being developed.

Involve customers in the bug finding journey

This needs to be a management and marketing level decision - involve your customers in the bug finding process. Ask them for feedback, have formal ways of checking back for issues, reward them with freebies when they find bugs. Customers are the ideal QA of a software, they use it everyday and they use in ways that your dev team would not even think about using a software (e.g using MS Word for image editing or Power point to make web pages!).

Microsoft has a thing called bug bounty which literally inspires users to spend time to find bugs and be rewarded for such efforts. Google has it’s various reward programs for finding defects, these are all examples of far sighted companies who have not only accepted bugs in live products and made it easy to report - they are actively involving the customers in their journey to find and ultimately fix those bugs.

Have workflow for updating users about bugs

As you accept bugs as reality, your wording and communication will let your users also accept them and make them expect you to come up with fixes as soon as they are found. They also expect you to be mature about bugs found in the current system and have a place to know about such bugs and the status of those fixes. User forums are great for such things and modern ones like Zendesk or Uservoice and many others like them do a great job of updating users about bugs, getting their feedback and letting them know when things are fixed. They have also the feel of user communities and can lead to bigger and better things such as users helping each other out and users forming their own groups to teach each other.

Create a culture for celebrating finding and fixing bugs

Finally, the most important thing of all - within your company and your development team create a culture of celebrating the finding of each bug and fixing them. Some companies make the fatal mistake of making the dev team feel bad each time a bug is found - this creates the negative emotion that takes away the enthusiasm and spirit the team needs to polish off a released product over time. To a dev team the release product is their own creation - any bug would sound bad to them anyway, it defeats the purpose if the company culture is to make them feel worse. The culture should be that bugs are unfortunate yet inevitable - but once found how fast they are resolved and an updated software is released is the true sign of a great software company.

Trust me on this, after more than two decades in this bug creation, I mean software development business, this culture fix is the biggest thing that differentiates a great software company from the others.

The no 1 skill for software founders

#1 skill for software founders (1).png

As a software founder you have to be a master of everything. You have to wake up with the motivation of Tony Robbins, morning routine of Elon Musk, run meetings like Bill Gates and finance like Jeff Bezos. It’s not easy. Yet, as a software founder, none of these skills and abilities are the number one skill that you absolutely have to have to be successful. That number one skill is

The ability to scope well

Or in other words, the ability to decide what features to do and what to leave out. This single ability alone can get you a software that you can afford to build and that people want and will pay for.

The good news is that this skill is something that can be learnt. Here are some guiding principles that can help:

The Pareto Principle

Way back in late 1800s an econnomist named Vilfredo Pareto came up with a simple idea:y 80% of the effects come from 20% of the causes. This is now known as the Pareto principle that gets quoted in every where people are trying to choose what to do and what to leave out.

It sounds too generic, too optimistic. Yet the funny thing is you’ll find over time it’s spot on. OK maybe not exactly 80% to the dot, but close enough. In the software context you could rephrase it as: 80% use of a software comes from just 20% of its features. So - if you could get to those 20% only you’d make most users happy. Think of the huge benefit, 20% of the costs (and time and effort) to get you enough of a software to go to market.

Another place in software where this 80-20 comes in is fixing bugs. Software will have bugs, but if you can find the right set of 20% bugs you can probably cover 80% of the issues. There’s a famous story (probably true) of Microsoft’s ex CEO Steve Balmer sending out an email about how this has clearly been proven by stats on bugs on Windows XP.

So be aware of the famous Mr. Pareto and learn to hone your skills for finding those magic 20% of what needs to be done.

The MoSCoW method

The MoSCoW analysis is a simple process for identifying priority items. It’s used to classify requirements into different groups according to their significance to the customer.

The process of MoSCoW analysis in software requirement analysis involves taking each possible requirement in your software and putting it into one of the following sets:

  • Must have : Something that must be done. Without it, it doesn’t make sense to release the product.

  • Should have: Something that should be done. You can live without this feature, but you risk losing a significant amount of customer interest if it’s missing.

  • Could have: Something that could be done. It’s a “nice to have” that makes the product better for your users, but at the same time it isn’t all that critical for your success.

  • Won’t have: Something that would be nice to have. If you’re done early, this is a nice, but really it’s neither required nor important to the majority of your customers.

Looking at these groups, you might think that such a grouping is something product management (or the product owner) could do on their own. But it’s really your job. Only you can see the full picture of time, effort, budget and time to market. The market (and your competitors) aren’t going to wait too long for your Must haves to be done. They’re going to move on. That’s why it’s important to do the MoSCoW analysis jointly between product management and engineering. If you can identify a Must have which isn’t feasible in a reasonable time-frame, you need to find alternatives, the sooner the better.

$100 test technique

This technique is described in the superb Managing software requirements (Leffingwell and Widrig) book. The idea is pretty simple:

  1. Get all the major stakeholders in a prioritization session and then make a list of features/items that need to be prioritized.

  2. Give everyone imaginary $100

  3. Ask them to divide the amount among the given options (user stories, tasks, requirements).

  4. Add up the dollars for each item once everyone is done and then you get to know which items are most valuable (and should be done first)

Five whys technique

The five whys method is part of the Toyota Production System. Developed by Sakichi Toyoda, the Japanese inventor. It’s the simplest thing on Earth, yet amazingly powerful in revealing hidden details of any problem. The process run by the analyst (usually you) asking the stakeholder (usually you again, so you asking yourself) repeatedly five times why the requirement is necessary until the importance of the requirements is clear. The answers reveal whether the requirement is really important or if can be delayed.

That’s it for today, if you really liked this and want to dig deeper, this is a hot bed of methods and techniques and recipes. Google and you’ll find a treasure trove. And if you want a superb book to read then the classics would be Agile Estimating and Planning by Mike Cohn and the aptly named Software by Numbers: Low-Risk, High-Return Development by Deene and Cleland-Huang

Making your software: Step 2 - Find software developers

Priya, our fictional software entrepreneur from the previous chapter on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. Now her big challenge is to find a software developer company who will turn her dream into reality.

how to find software developers.png

This is not an easy task. There are literally tens of thousands of software companies in the world. How would Priya find the software company that’s a right fit for her? Let’s try breaking the problem down a bit and see if we can come up with a strategy for finding the right software vendor for her. Let’s define what we mean “fit”:

For Priya, as an early stage founder, fit means the 3 following things in the order of their importance:

  1. The communications is good between Priya and the team that will work on her product.

  2. The cost of making the software is within budget.

  3. The software vendor understands the nature of early stage startup projects like Priya’s.

Let’s go over these points and see how Priya can find software developers with these points in mind and also check for the fit.

The Fit

Communications is the key

Priya is not a software professional so she needs to find someone who can communicate various technical jargon and issues easily to her. Even if she was a techie herself, as an early stage founder she might not have the time to focus fully on her project - since many early stage products are “side projects” where the founders have a day job to worry about. So Priya needs to find a software developer who speaks at the same wavelength as she does. A developer who understands well what she wants to build, her business priorities, the “low hanging fruits” she wants to pick and can tell her in simple terms what technical challenges there are, which decisions win her time, which compromises saves her money without losing a lot on features, etc.

Let me stress this once more: communications is the MOST important thing for a software project. If everything is perfect, if Priya finds the world’s best software team working at the just the right cost for her and she then finds that she can’t communicate with them well then she needs to look elsewhere. Simple rule, yet many early stage founders falter here. Maybe the cost savings or the flashy tech skills make them think it OK if there are some issues in communications. Sometimes they think “software engineers are like that, they will always speak in jargon and I have to accept that and try my best”. It’s simply not true. Software can be complex and obviously very technical, but a good software team will always ensure that there is someone in the team who understands software jargon, “nerdy” engineers and also business priorities and the founder’s thinking.

Staying in the ballpark matters

Cost is a big concern Priya, obviously. She has limited budget and she has fit all the costs for software development, hosting, advertising, travel, etc. in that. The actual specific number is something she will calculate as part of the planning that we will cover as step 4 in her journey. The reason for delaying this, instead of taking it up as an initial thing, is for her to get an idea about potential software development cost. Software development cost varies wildly depending on what she wants to make and also on the vendor she wants to use to make it. But whatever the situation she has an idea about the maximum she can spare for her project, e.g. she will know that she can’t spend a 100K for sure but she will probably be able to scrape out 10K. With such a number in mind she can then narrow down her search for vendors, taking out obvious ones out.

Experience with startups is important

Most early stage founder driven software projects are a wild journey. Pretty much all such projects start with a certain plan but end up being completely different. This is the nature of the game. The need and flexibility to pivot is extremely important for the success of Priya’s software. This is because both Priya and the software vendor doesn’t really know for certain what will be acceptable to the users of the software. Priya does a good job with her experience in dealing with her customers to find out the pain points and use the template in step 1 to create user goals and stories. But those are just her assumptions. They are tainted by her bias about what she believes her software can do. They are not test on the field by real customers. And she may find out really early on (hopefully) that certain features need to be changed a lot to meet what her customers really want.

The software vendors are typically in a blind spot too about Priya’s customers. They may know a thing or two about what features are good and what are confusing. They will definitely know (if they have the experience) that they should limit initial features to bare minimum focusing on the biggest pain points for her customers. But at the end everyone is shooting things in the dark. This is why the software vendor needs to have the understanding and experience about startup project like Priya’s. They should know that the project features, needs and timeline will vary as the project progresses. They need to plan for this possible change and accept it as the norm. Their experience will also help guide Priya towards taking the right decisions.

The selection process

Now that Priya knows about the fit, here is a process she can use to find and filter the software vendors. This process has worked for hundreds of our startup founders so we can vouch for this.

1. Compile a list of software companies and score their online presence and reference

Google will get you the names of thousands of possible software companies. But before Priya does that she should first reach out to her friends and family for any vendor they know or have an idea about. The best way to find a good software partner is through reference, it saves Priya a huge amount of time and energy. If the reference is really good and from someone she trusts, she should still do the scoring for fit as given below, but she can save time by not going through the compiling a list of candidates and comparing them. The referred company checks fine on fit, she can just go with them.

If Priya is relying on Google to find names, “custom” or “bespoke” is the right word to use to filter out software product companies (that make their own software only - like Microsoft) from the software consultancies that makes software companies for others like her. Here is a good search phrases she can try:

“Custom software companies in ________ “ (if she is looking for a specific location like her town or a specific country because she heard the costs are lower there).

Apart from google, there are directories where Priya can search for software companies - these usually come with reviews (take them with a pinch of salt though!), example projects etc. Here are some directories that are pretty comprehensive:

Clutch

Goodfirms

G2

When collecting the names of the companies it’s easy to get carried away and end up with dozens of names. It’s a big time waster to go through a large list, so it’s always a good idea to do a filtering even when compiling the list of companies to consider. Priya should look at the companies website and their work portfolio to see if they look good and have worked with early stage founders like her. Some custom software companies only work with big enterprises and their DNA will never match with what Priya’s project needs. Another important thing to check is how active the company is currently. Many software companies start out doing a few interesting projects and then lose their energy and become almost a relic that tries to leverage on past glories. Priya should look at company’s social media posts, recent posts and tweets to get a feel about how engaged and energized the company is. Another important check is looking at some LinkedIn profiles of key members of the company to get a feel about their experience and their involvement with the company.

Based on the companies online presence give them a score and if a company comes with reference you trust give them a score on reference. Our vendor selection spreadsheet template that you can download below has a cell for these scores against each vendor.

2. Email software companies and score the experience

This initial email itself is good way to test the candidates for fit and filter out some companies - that is where the scoring comes in. Here’s how: the email Priya sends out would be intentionally vague. She would of course mention she wants a software made, but not give a lot of details or give conflicting information. The reason is it to test the communications right from the start. Any reputable software company will prioritize incoming business leads like Priya’s email. So it would go through a certain workflow. In some companies it may go from customer support to a business team, in others it may jump directly to a decision maker. The flow, the time to respond, the process of clarification about her vagueness, the quality of the reply, the position of the person replying and the message itself will give Priya lots of hints about the quality of communications in that company. If, for example, Priya gets into a loop of emails, where she gets thrown from one person to another in the thread it’s a BIG red sign. It would probably indicates bad work process or communications channel at the company and something very similar would happen during the project. So, this initial email and the response is a great test (easy and low cost!) that Priya should score.

3. Run a survey and score the response

Now that Priya has list of software companies she should send out a standard survey to all of them and ask them to respond. The survey should address some of the basic issues she needs to know about a company so that she can compare them side by side, but also the survey should be done in a way so that Priya can use the answers to create a score for each company. When there are a bunch of similar companies, that all seem to offer the same services it’s always hard to compare, so it helps turn things into scores that can then be compared objectively. However the responses of the survey should also give Priya some idea about the company’s way of doing things, their culture etc.

We’ve given a template for such a survey as a spreadsheet (part of the download with this post). This will give an idea about what are good questions to ask in a survey like this, however each product and situation is different so the actual survey will probably need some tweaking. Separately it also makes sense to run the survey with a survey tool like google survey or surveymonkey

4. Call the top 5 companies and do a call. Score the experience

Now that Priya has 4 scores for each company from #1-#3 above she can get the top performing companies in that list of hers. Note that the scores are not all the same, they need to be weighted on the aggregate score. This is because a reference from a friend you trust is obviously a more reliable score than a random email thread that went wrong (maybe the person answering that email was a new employee who didn’t know the process…). We suggest a weighing in our template (downloadable below).

Priya can use the scores (and also her instincts - she may have liked a company much better than their score) to select a few (5-7 is a good number, too many is a time waster, too few is a bit risky) top performers and ask for a detailed call to discuss her current requirements. The verbal conversation is important as it will double check on communications. It will also let Priya test how pro-active they are. Note that this is not the call to discuss the product in detail or give them the rough spec (from step 1) to give estimate. That will be step 3. The reason Priya should delay that discussion is that she should get a non-disclosure agreement (NDA) done and also she doesn’t want to go through the time consuming requirements discussion with so many companies. Her goal is still to filter out maybe 2-3 companies with whom she will get to step 3 level details.

5. Calculate a final weighted score

Now that Priya has 5 scores: Online presence, reference, email, survey and call, she can do a total score. But not all the scores are the same value - so a simple average won’t be a good idea. We suggest making weighing reference and the call the most. Here’s our suggested formula for the weighted average score (it comes with the downloadable template spreadsheet at the bottom of this post):

Weighted average score = [online score + (3 X reference score) + (2 X email score) + 3 X survey score + 4 X call score ]/13

Total score.png


Moving forward…

Now, at last, you have a spreadsheet with a list of software companies that are scored on their merit and you can do a simple sorting on the total score to select the top ones that you will actually spend time with to explain your idea and get them to give you an estimate - a “ballpark” price. Reason it’s still ballpark is that most companies would only give you a final “fixed” priced project if they do a more detailed specification with pictures etc. That takes time, and you only want to proceed to that after you know if the pricing will fit with your budget. A ballpark estimate helps you in this regard. If the ballpark is something that you can fit into your budget then you get into the next step, if a company that scored high yet gave a ballpark estimate way beyond your budget (happens a lot, software price varies wildly because of all sorts of reasons) you’ll need to get them out of your list. OK, onto the ballpark estimate then…

But that’s step 3. So we are done for today!

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.

10 Steps to Making Your Software Product

You have a great idea for a software.

You want to make it and launch it. But you are not sure how to move forward.

priya confused.png

This is one of the most common situations with first time software entrepreneurs. Things can be very confusing for software products when it’s your first time. Where do you find a good software company that will make the software for you? Do you first figure out how much it’s going to cost? How do explain your product idea well enough so that the software company can get you realistic estimates? How do you ensure that they keep their promise? How do you know if they delivered a good software product? What happens after the software goes live? What happens if it needs a fix or a change? There is a whole list of important questions that needs answers before you can really make up your mind and move forward.

But where do you start?

As a software company helping entrepreneurs like you for the past 16 years we know your pains. We’ve helped many entrepreneurs turn their dreams into reality and launch their products.

We want to share our ideas and experience in this new series of articles called the “Making your software”.

The Steps

Before you do anything, you should have a rough idea about the stages you go through to get your idea into a working software product. So here goes, the life story of a typical software product - from the perspective of the entrepreneur.

Step 1: A rough specification

This is just you (and your co-founders) writing up (or even better drawing up) what you want to build. Doesn’t have to be perfect, or even very detailed but the moment you start asking software professionals questions like how long, how much, etc. they will want this from you. So this is the first step.

We’ll go through some tools you should use to get the specification done and also provide you with a template that works great for a rough spec. Read the post at: Making your software - Step 1 - a rough specification

Step 2: Find and compare software developers

This is the most important step in the story. A good software developer (like us :) ) is the key to getting your product launched. They will guide you through the rest of the stages, giving you advice about where to compromise and where not to. It’s absolutely vital that you research a bunch of vendors and find the one that fits you the best. Remember that the fit needs to be with you - a vendor can be the best skilled, most experienced, etc. but if they don’t communicate at the same wavelength as you nothing will ever get done right.

In the upcoming posts we’ll go over the basics of what you need to look for in a software developer and get you a template form you can use to survey the vendors and then compare them.

Step 3: Getting ballpark estimates

Ballpark numbers are very rough cost estimates based on the specification (from step 1) you give to the developers. This number helps you figure out costs and plan your funds. Always get ball park numbers from developers you short listed from step 2. You’d think it makes sense to ask for a number for from everyone as part of step 2, but in most cases the number will either be too much of a guess or plain wrong. To get a reliable ballpark you’ll need to spend some time with the developer to go through your concept, answer their questions etc. And obviously you can only do that with only a few.

We’ll guide you through a series of questions you should ask and things you should clarify to the developer to get a good ballpark number.

Step 4: Budgets and funds

This is the nitty gritty of how much money you’ll need and when. How you’ll get the funds and pay the developers. We’ll do a post on typical payment strategies, expected costs throughout the lifetime of the product and financial planning.

Step 5: Select the software developer and an NDA

This is where you finalize the software development partner and setup how you will work together. The actual legal contract is important, but at the end secondary - since no legal write up can replace a good working relationship. It’s extremely important to setup an operating process - decide how the project will move forward, how you’ll see the results and give feedback, the timeline, etc. The non-disclosure agreement (NDA) is your protection for the idea about the product as the software company will require you to go over the details of your idea before they can give a final costing they can commit to. There are variations to this plan, but this is typically the path most companies take.

We’ll do a post in this series with a time tested foolproof process along with a typical NDA template that does the job.

Step 6: Brainstorming/wire-frames/mock-ups

Now that you have a software developer on board and a rough specification in hand it’s time to brainstorm the idea and turning that idea into a working piece of software. You start by pinning down the features into a list, setting priorities for the features based on business importance and technical difficulties. The goal would be to target the “lowest hanging fruits” first - do the features that your customers would love the most which are also technically easy. For startups this path is the safest, with the plan of rolling out a product fast and possibility of cash flow along with early feedback from real customers.

Once you have that list of features thought out the next step would be to create storyboards - pictures of the software and how particular features would work. The software company’s designers and product analysts usually walk you through this. They do these first without worrying too much about the exact colors by drawing them up on rough sketches - pen and paper works but a software tool is better. This is wire-framing. And then they start putting colors and logos on them to create mock-ups - the pictures of the exact look of the software. How much detail you do depends on your time-line, budgeting etc. But you absolutely need to do at least some basic ones to get an understanding about the features. At Kaz we do the preliminary part of this process free. Some companies charge for this too. So this is something you have check with your vendor to decide beforehand.

In this series I’ll go over some tools we use and give you templates for the features, specifications and wire-frames.

Step 7: Final estimate and a contract

Now that the software requirements are well understood on both sides (remember, your original idea and the exact reality of the software may have changed a lot during the brainstorming!) it’s possible for the software company to commit to a price. Usually the price is close to the ballpark number (our typical error margin is +/- 30%), so it shouldn’t come as a big surprise. But it’s always possible that the idea has evolved far from the rough spec you had (which was the basis for the ballpark). This is where both sides can sit and decide how to align things. One way is to break up the product in phases, and do the deliveries in phases to fit with your budgeting. Or you could be compromising on certain features (e.g. “let’s do the facebook integration later since it will save 2 weeks of dev time”) to reduce the costs. Once you have reached a decision on the pricing you do the contract. Again the actual contract is much less important than the relationship and the understanding of the project features and priorities, but obviously you need the legal paperwork. The goal in the contract is to try achieve something that’s a win-win for the ever changing world of a software product.

We’ll share a template that has been time tested on startup projects and discuss the important things to go over during this step on finalizing the price.

Step 8: Development

This is where the actual product gets built. The part we love the most! This also the most important, time consuming and expensive part of the full activity. So you absolutely have to get things right to optimize it and make sure the project moves along at the right pace, risks are managed and a process is in place that ensures that things are done over and over.

We are super experts in this space, and after a thousands of times on the merry-go-round of software dev cycles we have very specific ideas about how it should be done right. We’ll share them along with some reporting ideas in this series.

Step 9: Marketing Plans

Without your marketing plans you software launch will never work. This is something you’ll need to do in parallel to the development work so that you are all ready to go when the software is ready. You’ll need a lot of technical help in this regard - since a lot of the marketing will be digital marketing. User tracking, social media integrations, interfacing for customer support, SEO, etc. all need the software company to help you out in this process.

We’ll share a list and a spreadsheet to track these. You should use this to coordinate with the software company and also clarify the need for help in this front with them.

Step 10: Launch

priya wohoo.png

Wohoooo! This is the most exciting part. But this part needs very good planning to get right. There are all sorts of things like hosting, domain pointing, social media assets, launch activity planning, advertising assets and a million other things to worry about. Make sure you plan this before hand with the software company.

We’ll do our typical launch activity run down with you in this series and provide you a spreadsheet and a “cheat sheet” for launching your first product.

Life after the launch

Launching of a product is really just the beginning of your long journey as a software entrepreneur! What you launch first is just the version 1.0. You have to then see what the market actually wants, what you got right and what you got wrong and then roll out newer versions of the product with additions, subtractions and most importantly modifications. At the same time the marketing and sales part of the story should take center stage - since if you can’t sell the product you will soon run out of money! Along this same path is the need for maintaining the software - fixing bugs, patching the hosting server or updating a mobile app for newer versions of operation systems (e.g. “Oh no iOS 14 has changed everything and we need to fix our app for it!”).

We’ll lump up all the million things that you are supposed to do as part of your life after launch into a post and give you some templates and plans to guide you through this life!

That’s it folks! It may look super complicated but I can tell you it’s not once you learn the basics. When you have a good software partner (ahem, like us :) ) it’s even easier as most of this they will guide you through anyway. Also watch this space as we do the posts over the next few weeks. We are always here to answer any questions you might have. Just drop us a line to ask using the button below. Our startup project experts are always happy to discuss your projects!

At the end it is an exciting and intensely creative activity that I know you’ll love. Remember, if you don’t do it now, someone else will soon enough, so now is the time!

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.

The Cookbook: Persuasion

The cookbook persuasion.png

If there is one thing I wish I knew before I started creating my company, it would be the fact that persuasion skills are acquired skills. As a leader almost everything you do will require you to persuade and influence someone. Some people are good at this and some people are not. But the amazing fact is that it’s easy to be good at this. That’s because persuading people is a science.

persuastion skills.png

I remember clearly the day I learnt that persuasion is a science.

I was going through a very difficult time at the company. We were just a one pony show then, with our lone customer insisting for the big product release done in days. And my team was asking for weeks to just test it. This was the big launch we have been working for, and if we didn’t get it done on time I knew we’ll lose this customer, and along with them possibly the company. I had spent a horrible day arguing with the lead about how and why I need the testing done fast. It was one of those conversations which ends with both sides feeling they’ve lost the trust they’ve built up over time. I remember the last thing that the lead said, and in front of the rest of the team: “if you release this, this will be your thing only, we will never put our name on a product like this”. The use of the “we” was brutal, but I knew it was felt by everyone. This was the farthest you can go from the concept of a hearty company.

I went back home that day feeling totally lost. This was a time when I haven’t proven that hearty company was even possible. So the feeling of loss was far beyond just the worry that I’ll lose this one customer. It was a feeling that what I had imagined to build as a company wasn’t something that’s possible in the “real” world of business. That little voice in my head kept telling me that companies are the heartless dehumanized beasts they are because that’s what businesses require them to be, to survive.

I remember reading the chapter “Give a dog a good name” in Dale Carnegie’s how to win book that evening. And deciding almost as a last resort that I’ll just blindly try his suggestion of alter casting – “giving a fine reputation to live up to” to persuade people to excel. I went back the next morning straight to the team’s room, and instead of saying “You need to finish testing and ship this by next week” I said “I know it’s hard, but I know you can finish testing and ship this by next week”. Just a play on the words, a substitution really, no change in substance. I was expecting to be shot down right away, I felt really fake saying it. But to my amazement I saw a slightly different reaction to my words than the day before. This gave me the encouragement to continue, I kept to the script of alter casting, making it sound like I knew they would do it, I had the confidence they could. And I couldn’t believe the effect my words had. The same team, the same people, people who are smart and can easily see through my word play and the fact that I was in essence just repeating my words of yesterday, yet the results and the attitude was completely different. Almost immediately I felt that everyone was positive and was willing to at least try. The defensiveness of yesterday was gone. It was all about “let’s try” and “let’s do” as opposed to words like “we can’t”, “it’s impossible” or “never”. To this day I feel angry when I remember this. Why didn’t they teach this absolutely essential life skill? This should be taught in our schools along with our alphabets. This is a power that makes everything possible. A super hero skill that you can pick up in a minute. I felt like screaming.

At the end alter casting wasn’t enough to get us to ship by time, but we did manage to launch with a week’s delay. I am sure that we couldn’t have done that without the help of alter casting. And much more importantly we couldn’t have done it in a way that made everyone energized and happy.

Over the years I’ve invested on learning more of these social psychology science, I guess persuasion strategies is a better but less sexy description. Some of the skills can even be put into a set of simple steps that you have to follow to get the desired results. There is a substantial body of research work in this space done over the past 100 years, so this is very much body of knowledge rather than some pseudo-science or iffy motivation course.

There are many great laymen’s books that you can read to widen your view (starting with Dale Carnegie’s classic). As you learn these new ideas, you’ll find that you are practicing them and enriching your toolbox of persuasion skills with the ideas that work for you. Some of the ideas may rarely work in your context, in your culture or industry. Some are plain wrong, too weird, too sleazy to try. But some are just basic skills that you absolutely must know. The sooner you learn them, the better. You’ll be using them daily. I promise. Here’s my essentials list.

Alter casting

Give them a fine reputation to live up to, and they will make prodigious efforts rather than see you disillusioned.
— Dale Carnegie

Alter casting, as with my example, is simply stating that someone already possesses a skill or ability that you want that person to possess. You’ve probably used this on your kids many times with lines like “I know you are good in maths and you’ll ace this exam”. Alter casting works just as well on adults. You may have to tone done the words a bit and make sure that it does’t sound patronizing. It creates not just a positive effect on the person or the group you are targeting but it creates a real positive energy in anyone who hears it. As a leader you start giving an impression of being supportive and full of good vibes. So it’s really a no brainer to use at any chance you get. There are just three things you need to be careful about when you are using it:

a)      Make sure you are not sounding patronizing. For obvious reasons, you’ll sound fake and it will also start having a negative effect in that it will feel like the person you are using it on is not capable and needs your encouragement to move forward.

b)      Don’t use it over and over on the same issue when there’s been failure in the past. Over using it will just make it useless. When it works it works the first time, when it doesn’t you just need to do something else.

c)       For some people it never works at all. So identify that group and never use it on them.

As “science” it came into social psychology 1963 from research work done by sociologists Eugene Weinstein and Paul Deutschberger. But in the everyday use of this technique definitely came from Dale Carnegie’s book.

Yes ladder

The yes ladder is a technique of asking for small commitments and eventually asking for the big one. It works on the simple human behaviour of wanting to stay consistent. It’s known more commonly as the “the foot in the door” principle, since it’s a common sales technique of selling a lower priced product – thus gain a foothold with a customer and then up-selling a bigger priced product. It’s a yes ladder because the act of saying yes to someone leads to saying yes later on in the conversation.

As an idea it must’ve been known through generations of sales people, but as a science it came out during a series of studies in the 1960s done by Stanford scientists Jonathan Freedman and Scott Fraser (published first in Journal of Personality and Social Psychology, in 1966). In one such study, people in a California neighborhood was asked to install a big, unsightly billboard on their front yard with a public service message of driving safety. For obvious reasons less than 17% agreed. But within the same neighborhood another group of people were first requested to put a very small poster for driver safety on their windows and then two weeks later they were requested to put up that large billboard. In this group the people agreeing shot up to 76%. A clear indication that a small yes leads to bigger a yes down the line.

The most common use of the yes ladder in our context is when you are trying to reach consensus in a group. I usually start by asking the group if they agree on something that I know they will agree on, and then over the course of the conversation ask progressively difficult things to agree on to lead the group up the yes ladder of agreement. Let me give an example of how I might use this. A very difficult decision for a software group is to agree if they want to introduce a strict rule of estimating individual tasks in a project. I could try my yes ladder here with a first question of “Do we all hate waterfall?”. No software developer in their right mind would say they like waterfall (the antiquated software development process), so I would get my first yes. I could then discuss a bit about what’s not waterfall and then ask the slightly more difficult question of “Do we want to measure our work output?”. You can only say yes to that, because saying no makes it sound like you don’t care about your efficiency. You can see where this is going, right? I’m getting the group to agree on the obvious, setting their mindsets to say yes on topics that lead to my ultimate ask of “Do we want to put hour estimates on individual task tickets?”. The yes ladder conditions the team to say yes and the little commitments they have made leading to the big ask convinces them to say yes there too.

I have to cover the big question that must be coming up in your mind by now: “Isn’t this plain and simple manipulation?”. The answer is yes. Because you are using techniques, let’s call them what they are: tricks, to reach consensus. This is true for all the persuasion skills I mention here. If you don’t use these without proper judgment you’ll be causing harm – to individuals and to the company. You’ll be pushing your ideas forward at the cost of other possibly better ideas. So just as with any other great power, you need to be careful. Use it when you know persuasion is helpful in making a decision. Use it when your team goes into that hated analysis paralysis mode, or when there are endless meetings without any decisions being reached etc. Use with care.

Use because

The use because principle says that every request you make should include a reason to believe to make it effective. As a leader you might think “do this” is what you have to say to move the group. That is the command and control like leadership an army requires. But in a hearty company you need a consultative leadership – where the leader creates consensus in the decision she takes. And for this situation you need to add a “because” to your line and say: “do this, because”. Now the funny thing is that the part after the because, the actual reason to believe, just doesn’t matter a lot! The fact that you structured you sentence with a reason to believe, that you added a “because” to it, makes it do its magic. Weird, but it is science!

It all started when Harvard scientist Ellen Langer published the results of a study in 1978. Langer experimented with subjects requesting to break in on a line of people waiting to use a Xerox machine at Harvard. Xerox machines made copies of your documents, the hi-tech of those days, and student would line up for a long time to do something which we do instantly with our printers now. The table below shows the lines the subjects used the following requests to go to the front of the line and their success:

because result.png

Notice the amazing power of the “because”? The last line’s because was not giving any reason at all! But by merely adding the word because the success rate shot up to almost the same level as a case with a real sounding reason.

“These studies taken together support the contention that when the structure of a communication, be it oral or written, semantically sound or senseless, is congruent with one’s past experience, it may occasion behavior mindless of relevant details.”
— Ellen Langer

I know this from my everyday interactions with my teams. The mere addition of a reason to believe changes the team’s motivations. It’s a simple yet powerful technique that is creates inclusive decision making and compliance without pressure. I love the title of Langer 1978 paper that published the result:

“The Mindlessness of Ostensibly Thoughtful Action: The Role of "Placebic" Information in Interpersonal Interaction”

Don’t you just love science? :)

You Frame

Dale Carnegie’s sums it up succinctly when he says: “…the only way on earth to influence people is to talk about what they want”. You frame is framing your requests and instructions in a way that it aligns with what people want. So, for an example, instead of saying the “I frame” of “I need to ship this product” move to the you frame of “We need a break (so we want to ship this product and be done)”.

Dale Carnegie starts his chapter on this idea with story about how he loves strawberries yet when he goes fishing he would never imagine using strawberries as baits. He uses worms because fish loves worms. Obvious isn’t it? We can only convince people if we present the arguments to them with what they want. There is no point of saying what I want, since no one is interested in what I want. I need to find out what the person I’m trying to persuade wants and then try to frame my arguments that fits with his want so that he gets interested and agrees. Carnegie puts this principle as – “arouse in the other person an eager want”.

Of all the persuasion techniques I know, this is the one that I get to use the most. This has never failed for me, mainly because it’s so obvious. And the best thing about this strategy is that it forces you, the leader, to think from the perspective of your team. Sometimes this thinking alone opens up new ideas about how something can be done. However, finding the you frame in typical business wants can be difficult. Let’s face it, most business’ immediate request involves you to work a bit harder so that the business can make some money.

How do you find the you angle in such a situation? I re-purpose an approach taken from Stephen Covey’s famous 7 habits book: begin with the end in mind. I figure out what the win would be like at the end and then work backwards to find the wording that would work to frame the request. I’ll give you an example from a situation that’s very common in my space. As a software team we have to pick up work on new technologies all the time. There’s always some concerns about taking up a completely new technology in the team, people worry about their performance or their ability to meet deadlines. But one of the wins of taking up a new technology is the skill you learn that bumps up career potentials. I’ve always found that the best approach to take here is to make my team visualize what they will gain in their career from a project like this. A new technology is likely to become a high demand skills in a year’s time. So highlighting the fact that individuals will gain a great skill to mention in their CV creates an immediate “eager want”. Much better than saying “We need to use this technology to make our clients happy”!

Social Proof

We like things that other people like. That is the gist of the idea of social proof. If others like it then it must be good, it must be supportable – this is something that’s innately built into us. This is probably another evolutionary hand me downs – we survived more when we followed others. Social proof is the reason why we stay at hotels with more star in their reviews, we buy books that have more recommendations or we wear colors that others say suits us better. Sometimes we know that the social proof is fake, intentionally made up to make us consume or like. The classic one is the “canned laughter” in sitcoms. We know they are pre-recorded laughter, put in the end of jokes to make laugh too. But it works. And there’s enough studies to prove that it works, starting with a Smyth and Fuller (1972) who found consistently that you can make a group laugh at not so funny materials if you just add canned laughter in the mix.

To use this principle in your everyday work of making a team come to an agreement you’ll need to recruit someone as your sidekick. Ask the sidekick to support you at the right time during the conversation. The fact that someone else is approving your idea has an instantaneous effect on the approval of the group.

Another way I use social proof is to think up of examples from the past where my idea has worked and bring that up and point to someone I know who would agree with me. In this strategy you don’t need to have the sidekick setup at all. If you choose the correct story, it should resonate with someone in your team to support you. And you are on your path to social proof.

There is another issue in our everyday work life where this principle is very relevant, but in a very different way. Whenever you have group of people and a risky decision needs to be taken you run into a common human problem of “bystander effect”. This is related to the social proof principle – since no one is taking up the lead and committing everyone feels the social proof that they don’t need to take action either. This is probably the biggest cause of why big companies become slow at responding and reacting. There are just too much social proof of non-risk takers. In smaller organizations with smaller groups it’s hard to get that feeling of anonymity and people don’t get enough social proof to stay unresponsive. There is enough evidence to support this as a science, for example a study done with a staged medical emergency showed that when there’s just one bystander there’s a 85% chance of receiving help compared to 31% when there are five people. As a hearty company you have to address this issue and I cover this in a later section of my series.

Further Reading

  1. How to win Friends & Influence People - Dale Carnegie

    This is the classic book that probably started the trend of self help books. Worth a read just for the sake of reading a classic, but the ideas are very much relevant and useful today.

  2. Influence: Science and Practice - Robert Cialdini

    A classic in the psychology of persuasion where the author comes up with a list of common persuasion techniques based on extensive research work in this interesting area. A good read on it’s own, but superb also to build up your skills for convincing people to follow you - must skill in this business of setting up an organization!

    And if you are worried about how all these persuasion techniques can be used against you and how you protect yourself from them then each chapter in the book has a section on such defense :)

  3. The 7 Habits of Highly Effective People - Stephen Covey

    Hugely successful book about strategies of making yourself more productive. There are some ideas in the book that are good strategies for persuasion too. Good read, but the book could’ve been made much shorter - it keeps rambling on and on sometimes which I find very distracting.

  4. The Power of Habit: Why We Do What We Do in Life and Business - Charles Duhigg

    If you are fascinated by some of the ideas in this post and want to follow up a bit more on how we do things out of habit or without thinking this book explores this in detail (maybe a bit too details in some parts to be interesting). Worth a read. I liked it and it gave me a lot more to think about.

  5. Outliers: The Story of Success - Malcolm Gladwell

    This book has nothing to do with the topic of persuasion.

    But if you, like me, get fascinated by the fact that seemingly irrational human things (like decision making) can be codified with patterns and modified and predicted by science, then this is a book you should read. Well you should read this book anyway, it’s one of the most interesting books I’ve ever read. The tangential connection with the topic of the post and this book is that Gladwell shows how human genius and success are all dependent on certain factors. Follow the factors the genius seems like a natural outcome. You can be a genius too if you had just followed the steps, well you feel that way at least when you read the book :)

Talent is everything in software

I come across a lot of NDA (non disclosure agreements) in my work with startups with the next big ideas. And NDAs are good since it give both sides a sense of confidence in sharing information. But at it’s core I sometimes find a feeling that it is the idea that’s super precious and a big secret. I think that’s a mistake.

Ideas, are easy - “a dime a dozen”.

It is the implementation of it that makes all the difference.

And it’s the talent that makes the implementation possible.

Startup survival Tips (1).png

This might sound controversial. After all if Mark Zuckerberg gave out his idea of a social network that can connect friends and family (and random virtual “friends” who might or might not exist) wouldn’t someone else have built Facebook? Or if Elon Musk told everyone about his electric cars wouldn’t GM be building something called Gelsa today? Not really, you know this right? Friendster (with that golden metric - MAU - monthly active users in the range 3 million as early as 2003) , Myspace, Hi5(?) are just some other equally social and equally good at making strangers friends were already around when FB cam along.

Actually as late as 2008 when FB was more than 4 years old already, Myspace was the top social networking platform, and consistently beat FB in traffic. Facebook did little harm to Myspace's popularity; at the time, Facebook was targeted only at college students. At its top, when News Corp attempted to merge it with Yahoo! in 2007, Myspace was valued at $12 billion! And if you look at the chart here that shows visitor counts for MySpace, as late as 2011 it was fighting out ( and losing) with respectable numbers.

Myspace is definitely a story of how not to do things. There is a lot to learn from it’s demise and there has been a lot written about it, I urge you to read some. But I digress from today’s topic.

As for stealing Musk’s idea, electric cars are obviously nothing new. There working models even in the early 1960s! For a great video about a quick recap about this space check out the video here.

Anyway, getting back to my point, there was nothing unique or even new about FB or Tesla. They just made it right, their implementation was better than others.

If you look around you would find this to be true for almost any idea you can think of or any successful software startup you see you’ll find that the idea had been around, maybe no one built it or others built it but they built it wrong. Just check out Kickstarter the amazing quality, uniqueness and breadth of some of the ideas are just mind blowing. But how many makes it big? And when they do why? You’ll always find that it’s because of their implementation.

And behind any good implementation is the team that build it. So using simple logic we have:

Talented team -> Great implementation -> Success

This may sound obvious, but you’d be surprise how many startups gets lost in thought that they have the best idea in the world and whatever team works on it, they will make it a big success. I would strongly argue the other way and say:

Hire the best team -> Think of an idea -> Success

OK that probably doesn’t work for a lot of startup owners since obviously its idea first for most founders. But if you believe in that formula of talent first you’ll probably morph into something like below:

Idea -> Hire the best team -> Morph the idea -> Success

That to me is the best formula for a founder thinking of making her ideas come to life. Oh, btw, I have the perfect Dilbert for today’s post…

dilbert startup idea.jpg

How to reduce the cost of making a software?

How to reduce software cost_.png

As a custom software development company a common question we get asked is about reducing the cost of development. Software development is expensive. Even using relatively lower cost countries such as Bangladesh or Cambodia, a startup owner is likely to spend the largest portions of her funds on making the software. Yet software is only a piece of the story and usually the one of the first ones, huge costs waits for her in marketing and sales that she has to budget for. Hence cost optimization and reduction is an important strategy for the software development, and if done right can be a deciding factor for the success of the startup.

Here are some strategies we suggest to startups (and even established and large companies) to manage, optimize and reduce their software development costs:


Use an outside development company

Salary cost, particularly development salary cost takes up the largest regular cost of a company. An in house software team is invaluable, there is no question about it but when budgeting becomes tight, using an outside development team that can be dialed up and dialed down on short notice is the single best move a company can take. This gives them immense flexibility to adjust and control the cost on a regular basis and defer the risk of financial commitment of an in house dev team (which I think is essential once the software and business is established).

Source: Inc article

Source: Inc article

The graphic here shows the social sharing and marketing company Buffer’s average monthly costs. Thanks to Buffer’s open book policy this information is available for a live 7+ million dollar annual revenue company and will give a rough picture of how the costs are laid out. As expected about 69% of cost is spent on salary (for 64 employees when this data was taken).

In case of this example, the company has already produced its flagship product. The initial time when the product was being built would incur a much larger cost. For many software projects and startups this initial injection of fund can a big problem or might lead little or no funds for the marketing effort that will follow the launch of the product.

Finding good software development vendor and utilizing that vendor in an optimal way can give startups a huge edge over its competition yet keep the overall flexibility in its business operations.

Advancing the project tasks by non developers

Many software project tasks can be done in house by the founders or members of the existing team. Getting these tasks done would mean that the total effort by the software development team (in house or outside vendor) would be reduced. This leads to higher productivity for the team and obviously less cost per feature.

A great example of project tasks that can be done by a founder herself (or non developers in the team) is the creation of initial product ideas and wire frames. Sometimes founders approach dev teams just a list of ideas say in an email, this means the development or product team has to work to turn those into usable specification. This requirement analysis cycle can be quite prolonged if the founder or key stakeholder hasn’t fleshed out the ideas well and has to go through prolonged sessions involving members of the technical team or the outside vendor. The whole process can be fast forwarded and compressed if the founder can think through the ideas and use an easy to use mockup tool (our favorite is of course balsamiq ) draw out the ideas. The whole requirement process then gets cut down by as much as 80% in our experience.

Non development stakeholders and founders can also help out on many other areas of the software development process like testing, helping with documentation etc. All of these add up to create substantial reduction of costs for making the software.

Keeping the requirements stable

One of the biggest way of increasing cost of a software project is feature creep or constantly changing requirements. When a software development team has a clear specification it can plan and implement the features at a very fast pace. But as soon as those initial specifications start changing or new features start creeping in (because “business demands it”) the cost of rework and changed priorities will also pile up. Over time this single cause lead to cost increases by 100-200% if not controlled in our experience. So this is a single big area to be concerned about and control to keep the cost of software development under control.



How to find a good software developer?

Finding good software developers is probably the most important thing for any software venture be it a micro startup, a giant bank starting a new project or software company like us adding new developers to its team.

A good developer makes a software possible, it’s as simple as that. You can find a developer (there are millions out there just go to any jobseeker or freelancer site) with all the certificates in the world, you can pay him well, you can give her the more time than you had planned for, you can give him the best tools that money can buy but the output - the software she makes depends only on one variable - is she good at what she does. In most other professions as long as you get someone who has been trained to do his thing he will get the job done at some point - some faster than others, some better than others but the job will be done. But with software the number of years of training or the number of framed certificates is in no way a guarantee that your software will be made. Some people can make software (without a single certificate on his wall) and others just can’t.

How to find good software developers_.png

Given this situation, finding a “good” software developer is critical. But how do you find one? How do you know that someone is that “good” developer? Not easy questions to answer and even after 16 years in this business of finding developers we get things wrong sometimes, but I’ll try to share some ideas that might help.

1. Good developers are “get the job done” people

The first thing is to define what is “good”. The easiest is to say “good” software developer is someone who gets the software made :) But we would not know that right at the beginning when she hasn’t had the chance to make the software (and we definitely can’t wait for the project to fail and find out she wasn’t our choice after all). So let’s define “good” based on qualities we are seeking in a coder which we can somehow test:

Good is someone who gets the job done.

... the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.
— Joel Spolsky

In our profession you’ll find many (too many in my opinion) who are at the level of a University professor with deep theoretical knowledge about design patterns or Java history. You do not want them. They are going to waste your time by thinking too much about what’s right and what’s not. You want someone who might know everything about Java but can go into a piece of code, use google to find answers to his questions and put in a band aid like fix without any guilt complex about his lack of knowledge! You need someone who gets the job done. Someone who can play a multi-hatted role in the everyday business of software development. Joel used to call these rare people the “duct tape programmers”. A good read in this line of thinking is Eric Sink’s superb little timeless piece You need developers not programmers.



2. Good developers are not afraid to write code in front of you.

Would you hire a magician without asking them to show you some magic tricks? Of course not.

Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them.
— Joel Spolsky

You hire developers to write code. So it is a very natural expectation that they should be able to write code right in front of you, right? You’ll be surprised about how often great resume holding (and of course certificates… OK you get my irrational bias against certificates…) people will just be too scared to write code in front of you (say during an interview). Or they’d just be all over the place with the code and come back to say something like “this will need to be refactored of course” or something fancy like that. Run. Run like mad from any developer who can’t start writing code at a moments notice. Good developers should be better at expressing themselves in code rather than in language.


3. Good developers come with references

Joel SpolskyAuthor of the best blog in the world for software development experience www.joelonsoftware.com

Joel Spolsky

Author of the best blog in the world for software development experience www.joelonsoftware.com

This one so obvious that I won’t delve too much into it. But leave by saying that before a developer is called the quality of their reference from someone you can trust (rather than their resume) should be the big marker. You see good developers easily make themselves felt. So every manager, team lead, business owner knows who is good very easily just from experience. Because they have gone through and got (or did not get) their software. Only downside is most manager don’t want to lose their good developers and want to get rid of their bad ones, so you got to be careful about whose words you trust! Our trick has always been to find our own references from peers rather than bosses.

4. Good developers are found in forums

Good developers are often found lurking around in tech forums asking and answering questions. Stackoverflow is definitely the big one, but there are many others. So finding links to their stackoverflow status or contributions should be a good thing and similarly if you are desperate forums are a good place to seek these rare individuals out. Microsoft is infamous with this trick, we’ve lost several of our super stars with MS poaching on them all the way from Redmond. Imagine getting a call from MS one night? Who can fight with the gods? D… the Internet :(

OK before I lose it I’m off. Hope you find your good developer and if you can’t just get us to build your software for you, we are best after all :p


A/B Testing the culture of your company

Wouldn’t it be great if you could A/B test the policies that you take for your company just like you A/B test user adoption for your designs? If we could somehow try our decisions out and then take the one that works better it would take the heartache out of a lot of everyday decisions.

Let’s face it, the way we run our companies, and I’m talking about everyone - from the mini startup to the mega corp., is purely a version of gambling. Let me break down some of the common “rationale” for our policies for the company -

Gray Abstract World Intellectual Property Day Social Media Graphic (1).png

Excuses for bad policies:

“That’s the way it’s done everywhere”

And probably that’s why most companies have dismal work cultures.

“If we don’t do this now, things will go out of control”

As if it’s a kindergarten we are running or worse a prison :(

“There must be checks and balances”

Yeah, but when you have to say it out to justify a policy chances are you are forcing something in that’s no check and no balance.

Anyway, you get the picture (and this is just a rant post). Getting back to my point, A/B Testing - most of the times we are never sure if the policy we are putting in place is a good policy that makes the company efficient and makes the people happy (yes, you can have them both!) or if it will just sap the soul out of the people and lead to inefficiencies and backstabbing. Take the classic “Performance Review” the classic “That’s the way it’s done everywhere” thing. Is it good or bad? Without a performance review your best people will not feel they are being prized or valued. But with performance review aren’t you bringing in competitiveness? Particularly in software development doesn’t the best coder in the world go through a patch of really bad performance (which is offset by 10X performance at other times)? There is no solid gold answer - only “buts” and “ifs” and “depends”. btw if I’ve got you riled up here’s a good read from HBR - Why More and More Companies Are Ditching Performance Ratings

So if we just had a simple way of trying out a policy (maybe in part of the company) and trying something different (with another part) and the checking for the results and pick the one that’s better. Anyway without a foolproof system for A/B testing here’s what we do at Kaz whenever we we trying to put a new policy in place or change an existing one:

Have a “feel out” phase

Every policy we adopt goes through a “feel out” phase where it’s discussed formally and informally during team meetings, lunches even hallway discussions. This gives early feedback about the policy, get amazing ideas of what might work and what might not work and works as great PR campaign for the policy.

Introduce incrementally

All policies are introduced very slowly and in parts. This makes it easy for us to find our mistakes and fix them without making a huge mess. It’s amazing how many times we have fallen face in even when the plan sounded great during our feel out.

Seek feedback

This is the important one - seek feedback from the people who are most affected by the change. There might be some very good ideas about tweaks that might work.

Be prepared to change or roll back

Nothing should be set in stone. As long as we achieve the goal we should not bother about how we achieve it. So if something doesn’t work just change it or roll back. Remember that it’s not a prison that you are running and there is absolutely nothing wrong for a company to admit that it was wrong.

Measure company culture

Now this is hard one. If you can’t measure and put numbers on culture you can’t find out if something is working better or making things worse. But it’s not easy and some would say next to impossible. Our thinking is that you don’t really need perfect system (there is none), as long as you have some measure it’s better than none. So a simple poll might be a good way out, or you can go the full Titanium card path and try something like MIT’s sociometrics (MIT being MIT had to come up with device to measure culture):


We wrote a series sometime back on how we do and did things in quantifying culture The method doesn’t matter as long as you have some way of understanding the effects that you policy changes are causing.

But still, we would love a scheme where we could do those A/B tests easily. Maybe MIT will come up with something? :)