Kaz Software's leadership in MIS Development in Bangladesh

In the landscape of digital transformation of the NGO sector in Bangaldesh, few companies stand out as prominently as Kaz Software in the realm of Management Information System (MIS) development. With a rich tapestry of successful projects, we've honed our expertise to become industry leaders, delivering tailored solutions that empower organizations for impactful change.

Diving into Success Stories: A Glimpse into Our Expertise

Dynamic MIS for Good Neighbour Bangladesh (GNB):

Our journey in transforming project management for Good Neighbour Bangladesh exemplifies our prowess in developing enterprise-level MIS solutions. By replacing outdated paper and Excel-based systems, we introduced a web-based online platform and an Android application. This not only streamlined GNB's operations but also paved the way for a paperless and more productive work environment.

Here’s a little video about our ongoing collaboration with GNB.

UNICEF Education MIS

Our collaboration with UNICEF on the Joint Response Project (JRP) exemplifies our prowess in developing specialized Education Management Information Systems. Focused on enhancing the efficiency of education centers, our platform brings together student information, educational organization details, and GIS data. Through meticulous software development, we've empowered UNICEF with tools for streamlined data collection, surveying, analysis, and visualization on GIS maps. A key feature of this platform is the Management Dashboards. These tools provide a holistic view of project progress, facilitate reporting, and enable Key Performance Indicator (KPI) tracking.

Oxfam's Digitization of Fecal Sludge Management:

In collaboration with Oxfam in Bangladesh, we ventured into the digitization of fecal sludge management at UNHCR camps. Our Android application, coupled with spatial prediction models and a web-based control interface, showcased our ability to develop comprehensive solutions. This digitization not only improved data accuracy but also provided a user-friendly interface for efficient management, garnering praise for its impact on living conditions.

During the project, the technical team has had to do several field visits at the actual camps to understand the requirements, interact with real users, find issues (e.g. cell phone coverage), training, etc. Here are some snaps from those visits.

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

CCDB's Dynamic Project Monitoring and Evaluation Platform:

The Christian Commission for Development in Bangladesh (CCDB) entrusted us with the development of a Project Monitoring & Evaluation Platform and a Knowledge Sharing Hub. This multifaceted project required a unified solution for managing diverse projects, including data tracking, monitoring, evaluation, and knowledge sharing. Our team's expertise in requirement analysis, detailed documentation, and software development in Microsoft.NET/C# resulted in a robust system that is now the backbone of CCDB's operations.

During one of our many visits to the field offices, we made a video of about our collaboration.

Why Choose Kaz Software as Your MIS Development Partner?

1. Holistic Approach to Requirements Analysis:

We believe in understanding the unique needs of each client thoroughly. This commitment is evident in our detailed business process documentation, ensuring that our solutions align seamlessly with organizational goals.

2. Innovation at the Core:

Kaz Software thrives on innovation, consistently adopting the latest technologies to create bespoke MIS solutions. Our projects showcase a fusion of creativity and cutting-edge tech, delivering solutions that are not just functional but future-proof.

3. Proven Technical Leadership:

Our senior staff, including Project Managers and Technical Architects, bring a wealth of experience to the table. Their leadership ensures the successful execution of each project.

4. Impact-Driven Development:

Beyond technical excellence, we prioritize the real-world impact of our solutions. Our MIS platforms are designed to enhance organizational efficiency, reduce costs, and amplify the positive outcomes for both the organization and the communities they serve.

Embark on a Journey of Digital Transformation with Kaz Software

Kaz Software's journey in the MIS development landscape is a testament to our unwavering commitment to excellence, innovation, and positive impact. As you consider your next MIS development partner, choose a company that doesn't just build software but crafts solutions that transform organizations.

Contact Kaz Software today, and let's embark on a journey of digital transformation together! #MISDevelopment #DigitalTransformation #KazSoftwareInnovates

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

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.

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!

Software that looks at animal footprints

Software is everywhere. Our lives are run by software these days, from the very moment we get woken up by the alarm on our mobile to the time we go to sleep listening to music playing on some software. So it’s hard to surprise we with yet another new take on the uses of software, but a recent read about a new way of tracking animals caught me off guard.

Called footprint-identification system (FIT) these systems analyze the picture of an animal’s footprint to find identifying marks, uses a global database of such marks to pinpoint animals, their age, sex and other properties.

The idea came from working with local trackers in Zimbabwe. These footprint reading experts can look at footprint on the mud and actually identify an individual animal. This led Sky Alibhai, co-founder of WildTrack to come up with a software solution that utilizes the strategies of the indigenous trackers by leveraging the AI and data crunching abilities of a software system. The working system WildTrack is now operational and is being used by scientists to track Rhinos and keep them safe from poachers who kill them (did you know that as recent as 1960 there were more than 100,000 black rhinos and yet by 1995 that got to less than 2,500?).

To use the system, scientists gather rhino footprint images with their smartphones and then use an app on the phone to upload the pictures to the serverside system. The FIT software on the serverside then processes that picture, compares it against it’s large database of pictures to identify the individual animal and store it’s current location and other geographic data that comes from the smartphone app.

What an amazing innovation, check it out at: How the FIT works

Introducing new features in your released software

Imagine this: you have released your software. As with any software releases, you had cut corners, last minute compromises had to be made, features had to go out without all the bell and whistles, etc. Yet, you users loved the software, and they have started to use it. As you start getting new users, you are also starting to get requests for features you had compromised on during the release. And people are complaining a bit about the UX, there were things you had thought made sense but it’s not so obvious for your users. You now realize that you have to update your software with a new version.

The good news is that it’s a web app, so updating is just releasing a new version overnight, making sure people’s data isn’t lost and you are done. But the bad news is that your UX fixes and new features mean you’ll need to revamp how the software will be used and the interface is likely to be completely redone. It’s bad news because you know that some people will get confused with your new UI because they’ve learnt your current interface and are using it.

What do you do?

Here are some strategies that we’ve been advising our clients with and they come from working on hundreds of app releases and update.

Release often, but only at the start

“Be agile; release early; release often.” that’s the the drill. But it is strategically wise to keep rolling out features only at the beginning of a product roll out when you don’t have that many users. When your product reaches a certain size, a certain number of users, you don’t want to risk the integrity of your application with every new minor release. The worst thing that can happen to your product is that loyal users, customers who have been using that one little feature consistently over the years, suddenly aren’t able to use it in the same convenient way. The change might empower users more, but the experience becomes less straightforward. Frustration and anxiety enter social media quickly and suddenly, and the pressure on customer support to respond meaningfully and in time increases with every minute. Of course, we don’t want to roll out new features only to realize that they actually hurt loyal users.

So the plan should be:

Release early, release often only at the beginning of product’s life

Announce the release

You should have a list of its current users. Use that list to communicate that changes are coming so people are prepared. Plan on sending an email announcement, explaining your new upcoming plans, with dates and list of feature changes.

Create a video showing what’s going to be new and more importantly how it will improve things for your users. Remember, this not just a boring news of updated software but it’s an advertising to get your users excited about the new features. That excitement will help ease the pain of learning and adapting to the new interface or the new way of doing things. A lot of people are visual learners and this preview will make the changes feel less unknown the next time they use your software. Sometimes even a animated gif does the job well. Here’s google introducing a new feature with a very short animated gif.

Or basecamp doing a in app popup letting people know about changes that are about to happen. Trello does something similar with their “New stuff!!” fox at the top.

Have app Tours & Walkthroughs for new features

When your users use your app all day long a new update can greatly affect your efficiency. You can easily address that negative by providing a short and easy in app tour to re-teach user behavior and help users with missing or moved features. There are different types of tours, but the ones that point out and walk users through how to use a new feature and answer any common questions works the best in our experience. Gmail has a great one that you must’ve seen. Here’s one I saw recently that I liked.

The good news is that it’s easy to add these in app tours. There are several great products out there that makes it pretty easy. Try out Stonly or Intercom for a start.

Have a “I’ll try later” option

This may not be the easiest option from a dev point of view, but it would be wonderful if you can do it somehow - the option that let’s users use the old interface for a while. Very useful when your users have something urgent to work on and you come in with your all new shiny interface where nothing is where it was! Facebook has them all the time when they do their big UI shifts, but they are Facebook. But you don’t always need thousands of developers in your team to do this. Nifty tricks like having the older version still available on a server and click to redirect users to that version might suffice in some cases :)

Ask for feedback

Sometimes all it needs for your users to be OK with your changes is a simple “sorry for the changes, we welcome your feedback” message somewhere. This humanizes the software and let’s your users know that you are putting them in trouble and that you are willing to listen to them.

Remember how angry we would get every time MS would drastically change their interfaces? We learnt the new way of doing things but we were looking for some way to tell MS what then shouldn’t have done!

Anyway, software is always going to be updated, so you’ll just need a way to make those updates less obtrusive to your users. This is a fact of life! Happy software development…

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

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.

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.

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.

Source: MySpace’s Rise and Fall – A Timeline of Highs and Lows

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…

How to reduce the cost of making a software?

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

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 talk about your software before launch?

Buzz is everything these days. I blame Apple for this, remember those lines to buy an mp3 player called the iPod or worse a mobile phone called iPhone? But to be fair “buzz” as a marketing tool - to build up anticipation about products has always been there. Building up of anticipation leads to people talking and that leads to that most coveted of words “viral”. A famous example is the "Get your free email at Hotmail" that when MS started adding to their customers’ email circa 1996 to “talk and hint” about hotmail led to 12 million users in 1.5 years! Wouldn’t you love that for the software you are bringing out the world tomorrow?

“ ... could you put a message at the bottom of everybody’s screen.?”

“Of course we can technically do it,” Smith said.

“Oh, great,” Draper said. “And it can persist, right? You can put it on one message and if he sends an email to somebody else you can put it on that one, too, right?”

“Yeah, yeah,” Smith said, not convinced.

“So put ‘PS: I love you. Get your free e-mail at Hotmail’ at the bottom....”

— Conversation around how news about Hotmail might leak

So if you want to sell your that piece of software that you’ve been dreaming of, spending most of your time, money and energy on then you a have to talk. But how much do you talk? What do you say? Here’s some of our ideas from our 16 years of helping startups build, launch and market their software.

Always under promise and then over deliver

When you talk about the upcoming product to potential customers they will inevitably imagine that your product will do all kinds of things that it may not actually do. Since you are all hyped up and you obviously think your product is the cure for cancer you transmit that enthusiasm in your description. Which is great but if you aren’t careful the picture that your potential user is getting is beyond anything your product will ever be able to deliver. When you finally deliver the actual product, they are bound to be disappointed. Which will lead to bad reviews by word of mouth or worse over the Internet. This will hurt your sales in ways you cannot control. A recent classic (but completely unavoidable though given the situation) was the MagicLeap product. With billions of funding and amazing stories told the actual first version of the product could only disappoint. But if you consider the product by iteself it still is unique and amazing.

The only solution is to make sure you are under promising with the tacit knowledge that when you over deliver the surprise and delight will help.

Keep your dates flexible as much as you can

If you want to keep your promises, you can’t talk about upcoming release dates unless you’re willing to gamble. Software projects have inherent risks of delay. Something can and usually does go wrong, Murphy’s law always wins. Missed release dates leads to disappointment and frustration. And that leads to disregard. In these days of low attention span, once you’ve lost the attention, there is very little chance of you getting it back. So when you talk about your upcoming product keep those dates fuzzy - well you have to tell at some point obviously but say it as late as possible so that the date you say is a reliable one. “Coming soon” probably is too fuzzy but coming this summer is superb.

Keep the story consistent

Classic feature creep. Need to do a course to understand how to use your remote?

Right at the beginning think through what you are going talk about and how much. Keep to that script. If needed practice it. Every external touch point from the website to your chat with a vendor should stick to the original script. Slipping a product feature out means you better have that product feature just the way you described it - so describing it in different ways with ever so little bells and whistles added on is a disaster waiting to happen.

We see this a lot with new founders, who has been dreaming up their product for a while. The actual product that will go out on a 1.0 is usually just 10% of the founder’s original vision. It is a scoped, sane, planned set of features that led to a project plan and timeline. If the founder now drops in his ideas from the 90% that’s left out he has finds it extremely difficult to leave out - leading to the infamous feature creep that destroys software projects.

I have feeling that most TV remotes around this world are results of crazy CEOs bragging about how many things his TV can do over a drink too many :) I can never figure out what most of those buttons do…

Have a company policy about leaks

I know, most startup products are not as famous as Apple or MS and don’t have to have the dramas of leaving as yet unrevealed phones left on at bars. But still, if you are to stick with your story and your plan of keeping to under promise and over deliver you’ve got to put in a policy of what to share about the upcoming product in the company. Developers or designers working on the product will talk about their work with their friends and family. That’s normal human behavior about creative output. So if you don’t lay out a plan, that better be simple, of what and how much to leak you are likely to face a lot of heartache.

OK, I’m done for today. Here’s a great Dilbert for today’s feature creep fear that every developer has nightmares about.

Documents every successful software project needs

When you start developing a software product, you need an idea of what you want each component of the software to do. From the part 1 in this series on defining products 3 Questions to define a software product, you now know the essential questions you need to ask to define your product. Today I’ll be doing part 2 that goes over how you document the requirements.

Knowing why, what and how your software product will be isn’t the end of the line for the product managers. You need prepare the documents, lists of requirements, UX modelling, etc. to make your development process easier. These, seems like a long process but it also serves over time as well.

If you don’t have your requirements straightened out, then how can you complete your project. And not just you, your developers will often want to freeze their development process based on some initial works of the definition. Once that is cleared out then proceed with development. Some call it the classic waterfall paradigm. This doesn’t work in any situation.

So, what can you do, keeping in mind you are the middle man, your failure to capture the whole product will affect both your customers and your developers?

You create baseline documents of the product you are planning to build.

Baseline Documents

Baseline Documents are documentations of a product that is formally reviewed, revised and accepted in their current forms, to serve as a detailed definition of what needs to be built. A simpler form of explaining would be to say a “blueprint” of the software that you will be developing. These documents may include the following types of requirement specifications:

• Functional requirements

• Non-functional (technical) requirements

Functional requirements

Functional requirement documents help SPMs to understand the characteristics of the product we need to build for our customers. As these types of documentations process helps us to capture the business of the product that the customers are asking for. As SPMs, if your goal is to capture the “why” there is a need of this product you are building and the “what” you can do to solve those needs, then this documentation approach is “THE” way to start.

Sometimes, functional requirements are also referred as “Business requirements”. And definitely don’t forget to share this document with your customers, as they need to confirm that this is what they want you to build. This document will detail the business end of the software product as well as the “requirements”. The requirements take the form of lists and with the help of UX specialists, you can show the outline on how it will work.

Technical requirements

Technical requirement documents will help to understand the “how” that “what” will be build. Someone with technical perspectives, like a software developer, or engineer, or architect, will need to understand the “what” you want him/her to build. They often don’t want to understand the business criteria of the product. But with their help you will be able to create a step-by-step instruction of the product. This will help you to understand the timeline to build and test the product before you release or hand it over to your customer.

Techies will have discussions with regarding the requirements that you have outlined for them to work on and you will go back-and-forth with which requirements have higher priorities and which have lower priorities, in terms for release planning.

The SRS

You can store both of these requirement documentation in to a singular document called the Software Requirement Specification (SRS) documentation. This will be helpful for the whole project as you can outline the requirements in priorities, from higher to lower, for the release plans. Developers will also be benefited from this document as it contains all.

Additionally, SRS documents can may also include several other software, hardware, stakeholders and interface requirement specification to fully define the baseline’s component. The goal is to provide customers and the developers with a clear understanding of exactly what is intended to go into the upcoming releases. This practice of storing requirements in a solution allows you to maintain an aggregated set of both present and future release commitments.

I’ll finish with WC’s tradition today of stealing and posting a Dilbert strip without feeling any sense of moral turpitude!

Where is your voice? - Voice design principles

Voice is here to stay. With services like Amazon Voice Service and devices like Alexa or Google home coming up in every home this is the brave new world of software interfaces.

The paradigm shift started when Apple first saved us from the clunky commands in a black DOS prompt back in 1984. This led to the wonderful world of the mouse, the click, the drag and the drop. Then Palm Pilot (remember those green things?) gave the excitement of a tap (more a poke with stylus, but not bad) in 1997. Then Steve Jobs came back to save us again with his iPhone (note to self: do not give a link) in 2007 with it’s fancy touch, pinch, pull and elasticity. We have to thank Jony Ive and his genius for making us humans get closer to technology.

Now is the new shift to two directions - XR with its full immersion on interface where interface is everything to Voice and its invisible interface - Alan Cooper’s dream come true with the most unobtrusive interface imaginable - the no interface.

As with every new design paradigm shift the new world of XR and voice requires us to re-think, re-learn and re-discover the design, development and testing process of software development. We found this with our recent projects in VR in our development and even testing. The same is very much true for voice user interfaces (VUI). A new design principle guides this space - the situational design. Voice apps require that software be designed with:

“Voice First Design”

Voice first design requires us to re-learn our thinking about software interfaces. Here are some pointer to start this re-think:

Expect variability and be adaptable

Each user is different and their use of spoken words is distinct and variable. What works for one, even a group will not work for everyone. All your designs need to take this into consideration, make the interfaces adaptable to user’s change of voice.

…the designer’s job shifts from picking the one label that works best for everyone to providing a range of utterances …

Personalize and individualize

You need to create a personal experience for users, whatever the actual voice device is intended for or your software is used for. The way to accomplish this is very different from what you are used to say for a mobile app where you might have the same popup to display personal data such as list of favorite sites. In voice interactions the interaction must be personalized since the same interaction, say with all the members of a family in the house where your app is running, will feel robotic rather than real and approachable.

Voice-first interactions should offer richer design. They should be predictable yet varied and delightful.

Expect to be called anytime

Gone are the days where users will need to switch on a device, find your app, click on a button to find you and get you to do something for them. They will expect you to be always there, a call away. You have no hierarchy of options - everything is first level, everything is ready to be called at moments notice.

You don’t want to be like those dismal IVRs that keep asking you to press 1 for life and 2 for death, do you?

Converse, be more human

Voice is inherently human like. Users will expect human like behavior from your app. The formality and disconnectedness of an app running in your computer is gone. Users’ expectation will be of a friend ready to be asked something, waiting to help out. Just google what people have been asking Siri. This is the new normal!

OK, done for today, but I have to get Scott Adam’s stab at this new fangled contraption before I go :) As always stolen without a hint of guilt…

3 Questions to define a software product

Imagine you are in charge of creating a clear specification for a new software product. On one side you have your customer - a a high energy, super smart non-techie who flies off in tangents in every discussion yet has the most amazing business idea that needs a web and mobile app. On your other side you have software developers who want a precise software definition that goes over the nitty gritty of what the software needs to do.

What do you do?

Let me go over how we do this with our 3 question approach. This is part 1 in my series on defining software.

Back to the your problem:

How to define a software product?

Every software product we see on the market started from an idea. The idea came from the need. The need presented itself when there is a lacking of carrying out tasks.

This is where the software product management - SPM shines. Understanding the “needs” is the primary goal for any product manager. We use software solutions every day without understanding the true value of it. Mostly because we have it already. There was a time we didn’t have the most basic solution known to mankind, Emails. We can’t imagine that time when it took up to months to send a message, or “mail”, to another person living in a distance.

Then someone asked the question “why?”, the first step to designing a great solution is born with a word. Questioning the limits and vulnerability of the existing solutions. Once it was determined that the existing mail communication is ineffective, the new idea is born.

Then they asked the question “what?”, which is the second most important step to designing any solution. Now knowing the issues with the existing solution, questioning what can be done to improve it will give them more ways to think to replace the existing solution, or system, of communication.

Once they figured out what needed to be done, they asked the question “how?” they can replace the system. The final question to designing any solution, looking for the answers on how to replace the system gave them the access to the tools those were need to create the new solution.

The “why” the “what” and the “how”, the three fundamental questions to defining any products, or solutions. Understanding this paradigm can help any product managers gain confidence for defining products. Product managers’ lives becomes very easy when they understand the answers for these questions. To define a product that you are building, you must go through these questions in step-by-step process.

Understanding the “Why?”

First, the “why” will help you to understand the actual need of the software you are trying to build, for your customers.

The key to understand a product that you are defining, designing and developing, is to understand the need for that product. Without a clear statement of the need if you jump in to the “how” based on some rough ideas on the “why”, it will often result in a product with that don’t address the stakeholders’ requests (no matter how good they look and function well). Most of the time product managers can assume what the customers/stakeholders are talking about when they mention their need but to master it you must start with diving in to details at the beginning of your conversation with them. Ask them why do they need this software/solution, why don’t their current system/process isn’t working, how do they want to their current system/process to function, etc. once you gather the initial needs of your customer, document them to understand their lacking. Investigate the system that they are currently using. Research the answers that you might think is valuable to them and easier for you to design.

The ”why” often usually helps to describe the vision of the product.

OK, the comic strip on the right is just a joke but a really good one, the why should always be aimed at the end user not company that’s profiting from the software!

Awesome “Why?” joke thanks to rstevens

Planning for the “What?”

The next step is to find out “what” can you do to provide a solution (or a product as a solution) for customers to overcome their difficulties. A very good practice is to investigate the process on the Internet and see how many have solved this need. It always helps to learn from your competitors. One bad practice is to jump to the development phase. In this way you may not know for sure, that the solution you have provided to your customers will serve them longer, or they can get any value out of using it, with the tools and technology you used to build the product for the customers. You must be able to plan more than one solution for a single need and try to understand the flaws in them. You can also use the help of UX and other interaction professionals to develop mockups or wireframes to show how concept of the product you need to build.

The “what’ part of the process helps you to capture the requirements, feature specification and milestones.

Deciding the “How”

Now that you know why and what you are doing, you can now jump to code. The third step gets easier when you have finalized what you will be building and why. Now comes the challenge on “how” to build what you have defined. With all the materials, such as business requirements, feature requirements, UX, models, your life becomes more easier to decide on the technology you will be using and design milestones in building the product you defined. This part is where you can race to code to build the product that your customers desire. Developers and architects should be given the freedom to make decisions regarding the implementation process.

In another way of saying, the “how” helps “what” is required to be built.

Concluding

To put a product on the (hypothetical) shelf, product managers have to be very precise in what they define as their product, both for the customers and the engineers. Using the “why”, “what” and “how” approach will help you to achieve that more efficiently and precisely.