Why your software partner needs to be laser focused on product launch

Innovation is key to staying ahead of the competition in the software world. The process of developing and launching software - fast, on time, and on budget, is crucial for a company's success. That is why when a company is planning to build software, one of the most critical decisions a company must make is selecting a vendor with a proven track record of delivering projects on time and within budget. However, the benefits go beyond just meeting deadlines and financial constraints. Choosing a vendor with a pragmatic approach to software release, emphasizing early launches and incremental improvements, can be a game-changer for your project.

The Pitfalls of Delayed Launches

1. Increased Risk of Failure

One of the primary reasons to prioritize on-time delivery is to mitigate the risk of project failure. Sometime back we wrote a great post about why software projects fail and how to save them. It’s worth repeating some of the data from that post. The CHAOS reports published by the Standish Group is a study of software projects in a wide range of industries and countries. The CHAOS Reports have been published every year since 1994 and are great indicators of the state of the software space.  The 2015 report studied more than 50,000 projects around the world, ranging from small software projects to huge ones.  The results show clearly the trend that software projects are failure-prone. Take the summary pie charts in the report (shown below). The red is ominously present in all the three aspects that were judged - budget overflows, timely delivery, and feature achievement. In a more recent study, Gartner found that 45% of software projects get delayed by at least a month. So delayed launch is a real and present danger.

The longer a software project takes, the more likely it is to encounter unforeseen challenges, such as changes in market conditions, shifts in technology trends, or internal organizational changes. By adhering to a timely release schedule, a company minimizes exposure to these risks and ensures that its software remains relevant and effective in the ever-evolving business landscape.

2. Getting Features Right the First Time

Launching early and iterating allows for the immediate validation of core features. When a company delays its software release in favor of an extensive development cycle, there is a higher likelihood of investing time and resources in features that may not align with user needs or market demands. By releasing software in phases, companies can gather real user feedback early on, enabling them to make informed decisions about the direction of the project and refine features based on actual user experiences.

3. Early User Feedback is Invaluable

In the world of software development, user feedback is gold. Launching early allows companies to put their product in the hands of real users, gaining insights into its strengths and weaknesses. This early feedback loop is invaluable for making informed adjustments, identifying potential issues, and ensuring the software meets user expectations. Delaying the launch deprives companies of this critical input, potentially leading to costly revisions after a full-scale release.

The Pragmatic Approach to Software Development

1. Launch Early, Launch Often

A vendor with a pragmatic view on software development understands the importance of launching early and iterating frequently. This approach not only reduces the time-to-market but also allows companies to establish a presence in the market sooner, gaining a competitive advantage. Moreover, it creates a continuous improvement cycle where features are refined based on real-world usage, making the software more responsive to user needs.

The release early, release often philosophy in software has proven time and time to work. This philosophy was popularized by Eric S. Raymond in his 1997 essay The Cathedral and the Bazaar, where Raymond stated "Release early. Release often. And listen to your customers".

2. Incremental Improvements Foster Innovation

Rather than aiming for a massive, all-encompassing release, a vendor focused on incremental improvements encourages a culture of innovation. By breaking down the software into manageable phases, companies can prioritize key functionalities and respond to changing requirements or market dynamics more effectively. This flexibility is paramount in a landscape where adaptability is synonymous with success.

3. Cost-Effective and Predictable Development

Choosing a vendor with a track record of delivering software on time and budget ensures a more predictable and cost-effective development process. This not only protects the company's financial investments but also allows for better resource planning and allocation. Predictable timelines facilitate clearer communication with stakeholders, instilling confidence in the project's progress.

Choose your software partner well

The decision to choose a vendor with a proven track record of delivering software on time and budget, coupled with a pragmatic approach to release cycles, can significantly impact the success of a software project. Embracing a philosophy of launching early and iterating with incremental improvements not only reduces the risk of failure but also facilitates early user feedback, ensuring that the software aligns with market needs and user expectations. In the ever-evolving landscape of technology, a company's ability to adapt and innovate is directly linked to its approach to software development. Therefore, the careful selection of a vendor with a commitment to timely delivery and iterative improvement is a strategic investment that pays dividends in the long run.

Do you have a software project that you need delivered on time and on budget?

Contact us, we have a 20+ year track record of delivering software on time and on budget and we don’t want to break that record anytime soon!

Staff Augmentation vs. Project-Based Consultancy—Which One Wins?

Bringing in an agency to help build your software platform is a winning strategy - it saves you time, and stress and most importantly keeps you within budget. But businesses often find themselves at a crossroads when it comes to outsourcing solutions. Two popular options—Staff Augmentation and Project-Based Consultancy—offer distinct advantages and cater to different needs. Let's delve into the intricacies of each approach and explore the benefits they bring to the table.

Staff Augmentation: Unleashing Flexibility and Scaling Capabilities

Staff augmentation in software projects refers to the practice of supplementing an existing in-house development team with external, temporary personnel or skilled professionals. This external workforce, often provided by an outsourcing or staffing agency, integrates seamlessly into the client's team to contribute specific expertise, skills, or resources needed for a particular project.

Staff augmentation strategy has a lot going for it, here are some big ones:

1. Greater Control and Flexibility:

Staff Augmentation is a go-to choice for businesses requiring temporary skilled workers or dealing with short-term projects. It provides greater control over the team, allowing seamless integration with in-house operations. The flexibility to scale the team up or down ensures that resources align with project requirements.

2. Immediate Access to Skilled Resources:

One of the standout advantages of staff augmentation is the swift access to a pool of skilled professionals. This is particularly beneficial for projects with tight deadlines, enabling teams to hit the ground running without the delays associated with traditional hiring processes.

3. Cost-Effectiveness for Short-Term Needs:

Staff Augmentation can be a cost-effective solution for short-term projects. While long-term costs may accumulate, the ability to bring in expertise only when needed can be a strategic financial decision.

4. Integration with Existing Processes:

Augmented staff seamlessly follow existing tools and processes within your company. This ensures a smooth workflow and integration with established methodologies, enhancing productivity.

5. Skill Enhancement for Ongoing Plans:

Ideal for developers familiar with project goals but needing extra support, staff augmentation aids in executing ongoing plans to scale. It provides knowledge of industry best practices and can contribute to achieving long-term objectives.

Project-Based Consultancy: Precision, Expertise, and Defined Outcomes

Project-based consultancy strategy in software projects involves engaging external consultants or consulting firms to provide expert guidance, strategic planning, and hands-on implementation for specific projects within a defined scope. Unlike staff augmentation, where external resources integrate into the existing team, project-based consultancy is more focused on delivering a comprehensive solution or achieving specific project goals.

Just like staff augmentation strategy, project-based consultancy has it’s upsides, here are some:

1. Expert Guidance and Implementation:

Project-Based Consultancy shines when businesses seek expert guidance and execution for specific projects. Consultants bring in-depth knowledge and experience, offering valuable insights that can elevate the project to market standards.

2. Defined Outcomes and Timelines:

Unlike staff augmentation, project-based consulting operates on a fixed or project-based cost structure. This clarity in financials and a clearly defined scope and timeline make it easy for businesses to budget and plan effectively.

3. Strategic Roadmap and Industry Compliance:

Project-based consultants provide strategic guidance in uncharted territories, ensuring adherence to industry compliance standards. They bring a fresh perspective, introducing efficiency to development processes and paving the way for successful project delivery.

4. Specialized Skills for New Challenges:

Consultants are aptly equipped to introduce businesses to new challenges. Whether it's accessing a new consumer platform or venturing into a new field, project-based consultancy helps enterprises apply their core talents to diverse and unfamiliar scenarios.

5. High Security Standards:

Consultants are expected to adhere to stringent security standards, providing a high level of data security. Their commitment to industry best practices ensures that projects meet the necessary privacy and security requirements.

Here’s the interesting thing, it doesn’t have to be one of those options! You could actually mix them up to bring out the best of both worlds.

Strength in Combination: A Holistic Approach

These two approaches need not be mutually exclusive. At Kaz we have have done many software projects where we have had both a dedicated team of developers working with our clients as part of their core team and separate parts of the system being built at the same time for that client in project based format. This gives our clients the flexibility and cost-control at the same time getting the benefits of the dedicated team. The added benefit of such a combined approach is that a component delivered as part of a project based work can then be looked after by the dedicated resource team (augmented staff) that has the benefit of co-located with the project team. This makes solving issues, knowledge transfer, future extension fast and accurate.

Also, initiatives that start as project-based consulting may evolve into more hands-on commitments, and vice versa. The combined strength of IT staff augmentation and project-based consultancy can lead to enhanced product responsibility, end-to-end support, and ongoing intellectual property advantages.

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.

Software development with Unity

Unity is now a leader in games and any application that requires 3D visualization. It’s a platform that’s stable, has huge developer community support, great tools, very helpful documentation and an ever increasing software developer group - thus a superb ecosystem. Today’s post is an overview of this platform that we love and have been working on for several years. We’ll share our own experience along with a more generalized survey of the ecosystem for anyone thinking of moving to this space.

Unity the game engine

Unity started in 2005 with a very specific goal:

"democratize" game development by making it accessible to more developers

From the beginning the the focus has been on making a tool usable by everyone - be it in ease of use or be it in cost. And this focus has enabled Unity to achieve the great level of adoption it has now. Over the years Unity ecosystem has developed in to one of the most extensive in any programming ecosystems. Here are some of the big highlights of that ecosystem.

Multi platform support

Unity’s greatest feature is single code base that can target multiple platforms. So a developer can build an app for desktops, mobile devices like iOS or Android, Consoles like PS4 or Xbox, AR/VR devices, etc. all with the same code base.

Easy to use and learn

This is Unity’s biggest thing - it’s just simple to use. Within a very short time any software developer can have the environment setup and ready to create really complex games. Unity leverages on existing programming languages (C# and JS) and developer’s favourite IDEs. Thus the learning curve becomes very flat very soon. This makes the decision for trying out Unity for a software development project very simple as a test environment can be setup quickly and developers can try things out fast

Documentation, tutorials and templates

A big highlight for working on on Unity it’s support for knowledge. Developing a game in Unity is a smooth learning experience with accessible online tutorials and learning materials that Unity itself provides. This is then augmented by literally hundreds of other free tutorials and training resources from third parties. Specially valuable are the numerous YouTube channels dedicated to Unity development. It really helps an a new developer starting out her journey in the game development.

Video tutorials are particularly rich. Unity itself has hundreds of such video tutorials that go over in details of building fully working games. Apart from these tutorials and standard documentation Unity supports and continuously grows it’s library of template projects. These are backed up by even more templates from the Asset store (see below).

Awesome forums and community

Online forums are extremely strong for unity. The large community of Unity developers almost guarantees that any problem a developer runs into is already answered or can be answered very fast. Most of the larger forums are monitored by the Unity staff to support and answer questions directly from the makers of the platform. This overall support mechanism helps build the positive feedback loop of the community. Making it so strong. Unity’s own support portal: Answers.unity.com is a great example of how company supported public forums should be. Other forums include the good old stackoverflow’s Unity area, forum.unity.com

Rich marketplace for assets

The world of Unity comes with a marketplace where you can buy (or in many cases download for free) great assets (graphics, game objects, code, even full games). The Unity Asset Store is loved by game developers because it rich collections of pre-designed graphics, game objects and many more. The overall impact of having such a marketplace at your fingertips is the rapid pace of development in your project. Whenever you stuck for something - be it a new character in your game or some funky code or game logic you’ll probably find something in the assetstore to help you. This just speeds up your development by a large margin.

Flexible Licensing Model

Most projects and companies can start using Unity for free and then pay as they grow. That is the philosophy for Unity’s licensing. Most game engines are expensive have the most rigid licensing rules. This is just not the case with Unity. The Unity game engine, despite being a top platform remains at an affordable price, as compared to others. The free version has enough features get most of the common software projects and games off the ground and an upgrade to Pro version at a an affordable price brings in a whole pack of advanced features.

Analytics built in

Unity comes with built-in analytics that a game developer can use to setup their analytics. The engine is comprehensive and covers pretty much all the basic needs of analytics for discovering insights about the game and it’s usage.

With such great features it is no wonder that Unity-made applications were used by 2 billion monthly active users, with 1.5 million monthly creators! Unity is there to take over the game development space and it’s a platform to reckon with. So if you are thinking of working on a game or a software that requires 3D visualization then give Unity a spin.

All you need to know about bug reporting

Bugs are a fact of life in software. There will always be bugs, we just need to find a streamlined way of catching them, reporting them, fixing them and deploying a new version with at least that bug fixed. In this process of catching bugs and removing them from the software the role of bug reporting is vitally important. If not done right valuable time is lost in clarifying what the bugs was about and in the worst cases important bugs are either forgotten or deprioritized. This situation makes the software less usable and eventually if this situation continues the users stop using the software - which is effectively the death of a software. So today I want to go over one of the least exciting topics in software development yet one of the most important one - reporting bugs in a way that is effective, efficient and clear.

The bug report

The best bug reports are short with a step by step "how to recreate" section and an expected results section. It’s pretty easy to remember the rule for a good bug report. Every bug should have at least the following:

1. Steps to reproduce the bug.

2. What was the result?

3. What was the expected result?

By laying out the result and the expected result the bug report is clearly showing to the developer the gap. The developer can now use #1 to recreate the bug, look at the result and check why it’s not giving the expected result.

Here’s an annotated example of a great report from a really good post about how bug reports should be done.

Apart for the basic facts above, additional data such as screen grabs and links to the product page are always good to have. Something else that also matters is the context of the bug - if there was a special situation when it happens (ideally that should be part of the steps to reproduce, but sometimes it may be hard to put that in there). If your bug is related to a specific hardware device and you should attach your device ID, it helps the developers find the bug faster and fix it sooner.

Including as much detail as possible makes finding and fixing your bug faster, remember that when reporting the bug the state of the software may be completely different from the time when the bug is being re-created and fixed. Many times a bug that was reported cannot be recreated by the developer. The reason could be that a step was missed in the bug's description or the state of the software at that particular situation needs to be in certain way for the bug to recreated. I remember a particularly nasty bug that would only happen at the QA's machine but never on my dev machine. The reason was that the QA would always run the web app by clearing his cache which would create a situation very different from my one where a certain cookie was always set. So the bug was really about not managing the cookie's absence.

Sometimes there could be many bugs that you report without realizing it. For example if the application is doing something wrong in a situation where you expect it to do something different and you thought you had reported the only bug and then discover another one after some time, chances are that your first bug was actually two separated ones and not one big one. The QA needs to think through every bug to see how it happened.

As you can see, describing a bug is not as easy as it looks and chances are that if you report a bug like this: "I opened the app and clicked 'login' but I was on the 'welcome' screen and there was no way to go back", then it will be impossible for developers to fix that. And it will end up spending everyone's time.

The process after the report

After submitting your bug report in an issue tracker, it should first be picked up based on severity of the bug. If the bug is a show stopper, a bug that stops the software from working then it should be prioritized over all other bugs and if needed current development flow will need to be changed to fix the bug so that it hits the next release. If it happens not to be a show stopper but just an inconvenience, then it gets bumped down the list and is fixed over all other bugs that are also being worked on. The issue tracker should be available to the original reporter of the bug (maybe the QA person or even the user of the software) who can easily track it down and see the status of the fix.

Another important thing with a bug report is the history of the bug. Every bug should show when it was started, what happened during it’s fixing, the exchange in information that happened to clarify the bug and finally the fix and the confirmation of the fix. So a history of the workflow per bug is a must and every software development process should use an issue tracker that supports such history. The good news is most modern day issue tracker such as Jira, Github, fogbugz, etc. support this buy default. Even the simple trello board is good for this.

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.

How to be the best software team lead

Software team leads have a difficult job. On one side they are expected to be the top developer in the team, cracking every technical challenge that comes their way with the snap of a finger yet on the other side they are expected to be the “manager” of the technical team. Now this “manager” bit is the one that is always fuzzy - it ends up meaning a lot of different things to different people and the team lead also ends up trying to fill all those roles that is expected of her. Being a manager will definitely mean she has to coordinate the activity of the software developers in her team - for example assign, distribute and redistribute tasks, help out team members with tasks, resolve conflicts, resolve technical challenges, prioritize activities and tasks. But being a manager also may require her to interface with customers, other teams within the company, attend meetings with the management teams, fill out spreadsheets for accounting … the list is really endless. With all such disparate responsibilities the question becomes what do you do to become good at becoming a software team lead. Here are my top tips from years of managing software teams and progressing through the career from a software developer.

1. Always plan first

   Obvious, isn’t it? But you’d be surprised how often the software team lead is under so much pressure that she just jumps in and tries to “winging it”. This strategy may work once in a while but it’s a recipe for disaster. ALWAYS plan, even if you feel there is no time for planning - force yourself to do it. This is a habit thing rather than a natural thing. By forcing yourself to plan things out you are ensuring that you give yourself a chance to think through things and prepare for overruns, disasters and failure. I’ve this as the first one in the list because I feel that if you don’t take anything from this list you should at least take this one. This single habit can change how good you are as a team lead. You’ll come out to be confident, your leadership will be valued and you yourself will be less stressed.

2. Mentor and delegate

   Notice how I just don’t say delegate? Delegating is really the core skill of a team lead. It is what makes her successful. But just by delegating tasks that she cannot do to others she is actually harming the project. She has to ensure that people she is delegating to has the ability to do those tasks. And for that to happen she has to mentor her team. The best software team leads are great teachers - team members come to them to learn. They start getting a reputation for turning out great professionals and developers want to join their teams. The best team leads know that without investing in her team members’s skills all her delegated tasks will fail and the everything will eventually roll up to her, increasing her tasks at the end. So mentor your team, teach them what you know and then start delegating task with the assurance that they have the ability to do those tasks. A recent HBR post does a good job at explaining this well: How to stop delegating and start teaching.

3. Communicate clearly

   Communicating clearly the exact things that need to be done is extremely important. This is where the best team leads shine. The team lead has to interpret, break down and decide what needs to be done. It is the team lead’s job to then clearly communicate those task to her team. If done well, the amount of to and fro in understanding and clarifying the tasks reduces to almost zero saving time and increasing efficiency of the team. So setup good process for communications, use tools that help and setup standards. For example, an issue management tool like Jira can make a huge difference to a team performance if used properly. Putting up stories, breaking them down to features, tasks and grouping them to milestones is investment that will more than pay itself down the line in saved time in communications and mistake free implementation.

4. Avoid micro-management

   Good team leads learn to trust their team. Trusting team members means you don’t have to micro manage. Micro management is one the biggest mistake that a team lead can make. It wastes everyone’s time and destroys morale and confidence. Team members start feeling undervalued, and worst of all they start feeling less responsible as expressions like “the boss will change this anyway” or “the lead will help me finish this code” start floating around. Your team will become more dependent on you as you micro manage and you’ll find that over time you spending more and more time doing micro management rather than useful work. Avoid at all costs.

5. Stay on top of technology

   Big one for technology leads. Software teams have an inbuilt hierarchy - a pecking order - based on technical ability. Respect within the team is handed out based on this pecking order. As a team lead you need to be on top of that pecking order and the only real way of doing that is to keep up with the technology. It’s hard, given all the pressure of managing teams and managing customers but if you don’t keep up you’ll eventually lose the respect of the team. Even just reading a few articles and discussing with the team about what they are using can help in this regard. Another tried and tested way is go setup a tech seminar system within the team where team members share their knowledge - it helps you learn things quickly and also helps the team improve their skills.

6. Take some dev tasks

   This may sound counter intuitive for large dev teams. Team leads in larger teams tend not to take any dev tasks themselves simply because they just don’t have enough time. Yet taking on some task, even very small ones are of immense value for team lead. On the surface level it shows that the team lead is “one of us” to the developers, but more importantly it gives the team lead an idea about what’s going on at low level which she may miss out completely if all she does is high level architecture or team management.

7. Learn to say “NO”

   Last but not least - learn to say no. At the end there will always be too many tasks being thrown towards a team lead. A good team lead has to prioritize tasks and figure out what tasks can be done at a later stage or not at all. Coming out and saying no is an essential skill that enables a team lead to manage this process. Say no to task that has no immediate value to the project in hand, say no to non essential tasks the management sometimes send your way a classic example is the performance review in the middle of a dev cycle. Avoiding non essential tasks will lead to a better project, better delivery and at the end a better result for the company.

   Oh this one was way longer than I planned (see always plan first :) ), OK here’s a Dilbert strip that works great with the theme. Happy team leading everyone!

5 UX rule every software founder should know about

I’ve found that in my chats with founders I keep coming to some common themes. And it doesn’t matter if the founder has been working on technology all his life or if he has no idea about software. One of those common themes is the discussion about how to make decisions about the actual user interface of the features that she has been dreaming up. For the technically minded founder it becomes a thing of do I use this pattern or that, or a strong bias of of some type (e.g. “less is more”, “pop ups are banned”, or something along those lines) and for the non technical founder it’s usually a more dangerous situation of absolute certainty about how the feature should be (usually with at least 20 buttons and a lot of color). The recurring theme follows a common script where we listen to the instructions, we try suggesting some changes and are met with strong opposition and sometimes dismay and we then suggest we draw this up (hoping that we might tweak things during that process). In most cases at some point we can convince the founder to have an open mind and make decisions about the user interface and interaction based on a rationale and sometimes also a debate. I used to point everyone to my favorite Alan Cooper’s About Face, it’s one of those books that equally valuable to the professionals as it’s to someone with a passing interest in UX. But now I find it easier to point to the amazing https://goodui.org/ as first step about thinking about patterns and rules of thumb in UI/UX (probably a sign that many of our new founders are from a generation that is more used to online content, quick reads and youtube).

Over the years, there are some UX wisdom that kind of made sense the moment we shared them with someone who didn’t know about them (or someone who knew but just haven’t thought about that for a while). These “instant hits” are really good to keep in mind when you are thinking about software interfaces but they are equally good to impress someone over a drink! So I thought it would be a good idea to do a quick and easy list of great UX wisdom today. Here’s my list of 5 of the easiest (and probably greatest too):

1. Fitt’s Law - larger and closer click-ability is better

Simple and logical rule of thumb which says you should always make the clickables (buttons, links, menus, etc.) large and close to where your mouse is currently. It’s so strong and has so much data to support it that it’s a “law” ! To implement Fitt’s law here are the two simple things you have to remember:

• Most used UI elements should be on the edges of the screen. Because the cursor automatically stops at the edges, they will be easier to click on.

• Make clickable areas as large as possible. Larger targets are easier to click on.

Fitt’s law is why tapping on those bigger commonly used buttons at the bottom of the iphone screen (where your thumb is) is so satisfying.

2. Hide your “ejector seat lever”

This one is from Alan Cooper. Again, very simple, you would never put the ejector seat lever button which ejects the pilot from a plane next to a common thing like light switch - just because accidents might happen. Same in software, don’t put major decision action elements (aka… buttons e.g.) next to and in similar level as other lesser ones. See how gmail keeps the trash option far away from the others and make the send button significantly different it’s neighbors? Great job.

Here’s the section from the man himself. If you haven’t got this book, buy it, if you have anything to do with software you should treat this as your religious text.

About Face: The Essentials of Interaction Design

By Alan Cooper, Robert Reimann, David Cronin, Christopher Noessel

3. Fewer is always better

GoodUI

Not sure if there is “pattern” with that exact wording, but there are many patterns and rules of thumb that can be distilled into this simple rule of thumb. The rule is just what it says, if you have an option between two sets of UI both of which gets the job done then the better one is the one with fewer elements, fewer actions, fewer buttons, fewer picture, fewer .. ok you get my point. You’ll find many versions of this rule, say if for a form GoodUI just has it as idea #13

This is why Google’s insanely simple home page for search was and is still the winner.

4. Progressive disclosure

Sounds fancy but all this is saying is that you should not show all your features to the user in one go and overwhelm him. Just delay displaying advanced or rarely used features, push them secondary screens, this will make your software easier to learn and keep your users engaged.

By hiding complex things, you are making the initial interfaces clutter free. You are also giving the user the time to learn your software, get small dopamine hits of success as they successfully use the software to get their job done. For some of the features there might be no other way but to get the user to do all the screens, but use this pattern to just split it up and show the screens in steps - keeping the user happy and engaged. The goal is to show only essential information. Then get the users to take the next step. When the user completes a step, reveal the information in that new step, keeping current state visible. By keeping previous steps, users can change what they have put in. Here’s a much more detailed version of this pattern.

5. A clear primary action for every interface

Every interface you build must have a single action that it wants the user to accomplish - the primary action. Focusing on splitting the interfaces up so that they don’t offer a multitude of actions each leading to a new path saves the user from confusion and the complex task of remember where they are within your software. The primary action button (or element) should focused, highlighted and obvious. All the wording, graphics of that interface should support that single primary action.

If the interface is for submitting generating an invoice, there should a big highlighted button called “Generate Invoice” for example. Well, life isn’t always that clear cut, but you’ll find that you can always find a solution that pays respect to this single (or at least clear) primary action. And this makes the interface so much easier to use. Something as complex as gmail’s logged in home screen, that probably has at least 100 clickable elements and action item can still offer that primary action feel. Almost the first thing you notice is that significantly different Compose button that’s inviting you to click it.

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!