Building our way to better products
This post introduces a series about thinking and building software products.
Lots of things have been written about building software products, and lots of things will be written. We, as CTOs, Product Managers, Designers, and Developers, are working on products all day long. This is because we care, because we would like to build products that work, products that are great.
At OpenClassrooms, we care very deeply about this. Of course, we don’t aim to know everything. We’ve done a lot and have made some great products, but we’ve also failed sometimes. We believe that sharing our experiences can be meaningful and help others on their software journeys.
Before going further on how we build software products at OpenClassrooms, let’s take a few moments to consider what makes a good software product.
Building a good product
A product should produce value. Sounds obvious!
Value for the user, by delivering a product that responds to a need and delivers the most-wanted features.
Value for the business, by delivering a product that is sustainable and generates revenue.
Value for the company, by being part of the core product and increasing the company’s value.
We all agree that software products should produce value. But maybe you also remember plenty of times you’ve spent building things without thinking of the value that they would produce!
It could be a feature that is important for you, but for which nobody asked, it could be a feature that doesn’t make sense regarding your company strategy, it could be a feature for your company needs when, in fact, an external service could offer you a product that’s 10 times better and 10 times cheaper.
Building a product also means validating hypotheses without spending too much time on hypothetical valuable features. You can do this by defining an MVP or through the product discovery process.
Producing value should be the main goal, and measuring the value you’re producing should be the main metric. Because, of course, you need metrics!
Building good software
If you work at a company where the product is built on top of the software, you must take care of the software. This leads to the question: what is good software? Is it good practices like:
- Being agile?
- Using Continuous Integration?
- Using Continuous Delivery?
This helps for sure, but lots of failing applications use these concepts perfectly and fail. Maybe something more technical?
- Using this brand new language?
- Using the latest trendy framework?
- Writing good code?
Perhaps, but what is good code?
- Clean code?
- Tested code?
- All-these-acronyms code? (DRY, KISS, SOLID, TDD, YAGNI …)
Well, almost, but that’s not all.
These practices, tools, and code skills should guide your application to work and change.
After all, building good software means building applications that work and embrace change.
“Embrace change.” — Kent Beck
Building a good organization
One of the main sources of value of your company is the people who work at it. They understand the aforementioned topics, and they’re the ones that have worked, and will continue working on, your product. However, even if the people are great and talented, they need a good organization to support them. What makes a good organization?
An organization should fit your company: fit the people, the culture, the business, the company stage, etc.
It makes no sense to have a multi-regional organization when your business operates in one country, it makes no sense to have Spotify-like squads when you are early-stage and you have a 3-person product team, and so on.
But common things should be handle with care. Your organization should share the same values, should be user-centric, product-centric, data-centric, agile, etc.
A team should be expert-level but shouldn’t be a team of experts. Of course, you do need some! People should be autonomous as much as possible. These are the foundations for scaling.
Continuous improvements should exist so your organization will be more and more efficient and will always fit your company.
Everything else
Limiting a good software product to these three topics would be not fair. Other key elements are involved: Marketing, Support, Customer success, Branding, Communication, and more.
Unfortunately, we can’t talk about all the aspects of the product. We’re going to focus mainly on product management, design, and the technical parts in this series.
How to build a good application
Quite easy: build an application that produces value, that works, that embraces change with a good organization!
I wish that it could be that simple, but it’s not. Even if we know all of the above, it’s not a guarantee of success.
Lots of topics will be covered in the next posts such as vision, strategy, KPIs, MVPs, product management, UX, UI, development, QA, feature lifecycle, and much more.
Stay tuned!
