If you or your organization is ready to invest thousands of dollars on building a piece of software, you hopefully already have a good idea of who your users are and how they will interact with your product. You could be a subject matter expert, or your company may be a leader in the field that your project is targeted towards, putting you in a great position to provide background on what the software ought to do and how it should be used. What you’re looking for is a top-notch team ready to hit the ground running and build your software.
In a previous post, I discussed how Atomic Object engages with our clients in a phase of Research, Design, and Planning (RDP) at the beginning of each project to help define and refine a software product. If you’re well-prepared and grounded in your field, it could be difficult to see how this work could be worthwhile for your project, and skipping RDP may seem like a great way to save some money towards feature development. However, just a bit of time up front can pay off in a big way during the build phase of your product. Here are several ways an RDP phase can benefit a project. Read more on Strengthen your Software Investment with Research, Design, and Planning…
Surgeon Simulator 2013
Let’s look at a hypothetical situation. You have a medical issue requiring surgery. While there are many surgeons that could get the job done, each one has their own level of ability and skill. Through their choices, the surgeon will affect overall “quality” of the operation — which procedure is used, cosmetic results, general odds of success, and how any unforeseen complications will be dealt with. The surgeon won’t have a complete picture of the situation until the operation is underway, and even then surprises are possible, so overall skill is essential.
If faced with this choice, how do you determine which surgeon to hire? It’s not easy when risks are (potentially) high and your technical understanding of the field is low. Your choice could have a potentially dramatic effect on the outcome, and there’s no going back.
I imagine that this is very similar to how it feels to be tasked with selecting a firm to develop custom software for your business.
Read more on Beyond Domain Experience – 3 Qualities of Great Software Teams…
One of the traditional problems in software development is the delivery of a finished project. Atomic Object writes custom software, but we ultimately need to deliver it to our customers, which usually implies deploying it to an existing infrastructure environment, or handing it off to an operations team.
Unfortunately, this hand-off process often introduces a variety of glitches and bugs due to differences between the environment that the software was developed in (the development environment), and the environment it will actually run in (the production environment).
Vagrant is a tool for creating and configuring virtual machines. It provides an interface to easily bootstrap and manage virtual machines using a variety of different virtualization platforms and configuration management tools, both open source and commercial. By using Vagrant, developers can easily write and test applications in environments similar to which they will actually be deployed. This reduces the likelihood of glitches and bugs when handing off a finished project to customers. Read more on Why Vagrant? – Preventing Deployment Issues from Day One with a Virtual Machine…
Human-Centered Design (HCD) practices help companies develop innovative product concepts. From my experience, extending HCD practices inward to include a company’s information technology team increases the chances for success.
What is Human-Centered Design?
IDEO (a leading global design consultancy) recognizes that HCD involves viewing solutions through the lenses of Desirability, Feasibility, and Viability and building products that live at the intersection of all three lenses.
Read more on A Human-Centered Design Approach to Involving IT in Product Development…
When you are developing initial requirements for a new software product development project, you may find yourself questioning the appropriate level of detail to provide for specifications.
You may feel compelled to provide a high degree of specificity so the development team can create an accurate estimate of cost and time to build the defined solution. You may feel worried that if you miss something in the software requirements, the project — or even you — may be viewed as a failure. The good news is that you can loosen up! There is a better way to develop requirements, and it doesn’t include specifying every detail at the start of the project.
Detailed Specifications – Too Much Definition, Too Soon
The first step is to realize you probably should not be creating a detailed set of functional or technical specifications for a development team to build. It’s usually too early to focus on detailed specifications before the development team has an opportunity to creatively engage in the project at a broader level — including business and user motivations. Providing detailed functional and technical specifications too early can create a false sense that the problem or opportunity is completely understood, which can result in missed opportunities or inaccurate project plans.
Read more on Creating High-Value, User-Focused Software Requirements…
Buying custom software design and development services, especially for the first time, can be scary. There is clearly a knowledge imbalance between you and your service provider. They (hopefully) understand the effort required to successfully build your product, and you don’t. This puts you at risk of being taken advantage of.
I understand this fear. Any time my car is in need of repairs, I am paranoid that the mechanic will take me for a ride. Other than being able to drive a car, I know very little about them. There is a clear imbalance between my and the mechanic’s understanding of labor and parts costs. This puts me at risk. Read more on Why You Should Trust your Software Vendor – From a Guy who Fears the Mechanic…
Eric Ries defines a Minimum Viable Product (MVP) as
“…a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
An MVP usually targets early adopters and includes only the minimum amount of features to validate your value proposition hypotheses.
The practice of starting with an MVP is a lean startup tactic. To execute an MVP well, I suggest you study the principles behind it and the Lean Startup Methodology as a whole. Understanding Lean Startup principles will also be a great help as you build your company.
When Less Is More
Through years of experience helping clients build products with Atomic Object, I’ve found most product managers and entrepreneurs tend to overbuild their first product release. This is often comes from a fear of underbuilding – they want to know that they’re product is compelling enough for their users, and they don’t want to give competitors a chance to leap-frog them. I also believe overbuilding can be partially motived from another fear — a subconscious desire to put off the release and the prospect that your idea might fail.
Read more on Less Is More – 4 Benefits of Starting with a Minimum Viable Product…
Atomic works in close partnership with our clients, adopting their goals and becoming part of their internal team. This requires regular communication with the client’s product manager during every stage of the project — something we’ve very intentional about, especially when the client is too far from our office to have weekly in-person meetings.
To make sure remote software teams get and stay on the same page, we’ve created an approach for effective collaboration and communication that enables us to create a strong product, no matter how far apart our teams are. (Interestingly, this approach is almost identical to our process for working with local product managers.)
Read more on Working with Remote Software Teams…
So, you’ve decided to rewrite your software. The entire team is ecstatic. No one will have to deal with the old, hard-to-use, painful-to-extend mess anymore.
Since you already have working legacy software, you have the perfect specification for the new product. Planning what to do should be easy right? Not exactly. Creating software from scratch is all about “what can be,” but rewriting software has to start with a clear understanding of “what is.” And your existing application probably does far more than you think.
Before you jump in with both feet, take time to do some research. The better your information, the better your software will serve your users, and the happier everyone will be at the end of the day. Read more on 2 Essentials of Planning a Software Rewrite…
Congratulations. You and/or your company have a great idea for a software product, and you’ve decided to work with Atomic Object to build it.
At the beginning of the process, you’re likely feeling excited about your idea and eager to see things take shape. You may also feel a bit worried or daunted about the process of turning your initial concept into a real, functioning product. Whether it’s an iPhone app, a web-based product, a desktop application, or an embedded device, creating a piece of software is a daunting task that can span months, requiring many hours of labor and thousands of dollars. It’s important to get things started off right.
At Atomic, each project starts with a Project Kickoff session, which leads into a phase of Research, Discovery, & Planning (RDP). This phase of the project serves as a foundation for everything that happens afterwards. For me, this phase is one of the most interesting and exciting parts of working at Atomic, and in this post I’d like to share a bit more about the process and what to expect. Read more on Building the Right Thing – Define Your Product with a Kickoff & RDP Session…