Every step along the path to delivering a software project is a trade-off. Time and/or money are in short supply relative to the vision for a product, and every decision must be made with care. Moreover, there’s no one “correct” way to design or a build a feature—there are many possibilities, each with their own cost, time to implement, possibility for reuse, desirability, and maintenance burden.
Design and design thinking can’t solve all of the world’s problems. But design is noticed by others, whether your company/product has considered it or not. And design can make your product more usable and accessible.
From your website to your physical space to the way you respond to emails to your actual product or service, it’s worthwhile to ask yourself, “Is this designed the way I want my customers or users to experience it?” Read more on 3 Design Techniques for Non-Designers…
As the minimum viable product idea becomes mainstream, I’m starting to hear “MVP” used to justify any minimal effort. It’s great that people want to benefit from being lean and agile, but it’s also absolutely vital that an MVP answers your important questions. There are many kinds of MVPs and most of them are anything but minimal effort. Thinking of an MVP as minimal effort risks wasting the effort completely.
In software we often balance competing goals. I’m going to deconstruct the MVP as tension between three different kinds of questions. Thinking this way helps you prioritize what you want out of your MVPs. It’s more useful than trying to find the sweet spot on a Venn diagram of potential products. Read more on Minimum Viable Product: Pick Any Two…
Our clients come to us with really cool ideas for web, mobile, and embedded apps. Usually, they know their domain inside and out, and they’ve come up with a great way to improve the world with some custom new software.
But we’ve learned over the years is that a little bit of planning before jumping into the code goes a long way. Read more on Don’t Skimp on Research, Design, and Planning…
You are planning a software project, or working with Atomic to Research, Design, and Plan one. You’ve thought about your users, created context scenarios, and drawn up a huge list of features you’d love to have. But how do you prioritize that list? Read more on Charting our Features & Priorities with a Story Map…
This post is revised and republished from Carl’s blog at Crain’s Detroit Business.
When I talk with business owners about using software to automate an existing business process, the request usually goes something like this: “We have this clunky process to do X which uses an old buggy application (or spreadsheets or email). It drives the people who do the work crazy. We’re growing and really need to automate the whole thing. Can you help?”
Of course, custom software and even automation is not always the answer. Given the cost of software development, jumping into a project too quickly can doom the hoped-for return. I always start with a few crucial questions: Read more on 8 Questions to Ask before You Automate…
Atomic Object builds custom software for our customers. Because of the complexity involved in building a great software product, software development projects are always more difficult to price than a product.
As a result two different strategies for pricing services, such as building software, have traditionally been used by most companies. These are called “Fixed Price” and “Time And Materials”.
A Fixed Price strategy locks in the total price of the project upfront.
- Static Variables: Scope, Cost
- Flexible Variable: Quality
- Assumption: The estimate and plan are correct and will not need to be changed.
- Risk: On Consultant (Responds by inflating cost; may compromise quality if estimates are inaccurate.)
- Effect of New Information: Causes conflict about what’s covered by the scope vs. what requires a change order. New ideas are rarely incorporated.
In this strategy, the vendor is taking on all the financial risk of a project. They have committed to completing the project for a specific price. If they complete the job early, it’s a bonus for the vendor (and you the client has overpaid), if they don’t then the vendor loses. In order to mitigate this risk, they will want to know all that can be known about this project and the risks before it will commit to a fixed price. Read more on Fixed Price vs. Time & Materials vs. FBSC (Fixed-Budget, Scope-Controlled)…
Sometimes you shouldn’t spend resources on a custom software application. And sometimes, you should realize that you aren’t ready to create a software product.
Atomic Object gets hundreds of inquiries every year from people interested in engaging us to build a custom software application or product. Our ultimate goal is help our clients succeed in their business. That means we occasionally recommend deferring custom software, reducing the scope of custom software, or not building custom software at all. Read more on When Not to Build Custom Software…
First time creating a software product? If you are familiar with creating or selling physical products and are looking to get into the software product space, there are a few subtle differences that you should understand. These differences can make a substantial impact on your planning.
The majority of products that exist in the world today are tangible things. They are all around us from the food we eat, cars we drive, houses we live in, and trinkets we buy. As a species, we have been buying and selling physical products for thousands of years. We have internalized and accepted the economics at play (e.g. variable costs, mechanical failure, etc).
But what about software products? Have people internalized the subtle, but important differences? Read more on 3 Ways Software Products are Different from Physical Products…
Are you thinking about developing the next great mobile app? When creating your business strategy you’ll want to know:
- How many potential app users there are?
- What platform you should develop for?
- What apps have the greatest reach?
- What apps generate the most revenue?
The mobile app market is evolving quickly, so the answers to the above questions change frequently. In this blog post, I will report the most recent numbers, and also provide links to resources that you can use to stay up to date with the information you need. Read more on Developing a Mobile App? Some Numbers You’ll Need to Know…