Building SpecFuse for software project management

After we sold UltimateCSR in early in 2018, it was time to get started on something new. I always wished we had a better system for organizing our ideas, feature requests, and roadmap while working on applications in the past. I never found a product I was quite happy with, so we decided to create SpecFuse.

SpecFuse is a product planning and management application aimed at software projects. It helps you to get clear on what you are building, why, and for who, as well as managing your project as you create it and iterate upon it.

Here are some of the specific opportunities in other options that I wanted to address with SpecFuse:

I wanted something simple

I found other many other options to be very complicated. Particularly the larger ones that had added many features over time to cater for different requests and user styles. They had a lot of options and features to work through, leading to steep learning curves for new users. 

While developers and other more technical roles can get familiar with those more complex systems over time, they make it very challenging for others outside the IT department to jump in and collaborate.

We want to have something that everyone could quickly jump in on and participate. Something so easy to use that users could explore the UI, watch a short introduction video, and then be ready to go.

I didn't want to be forced all-in on agile methodology

I love being agile in terms of building for the user, and continuously iterating with short release cycles. However, I don't want always want to use the entire methodology in my project management system. 

Grouping activities into 'epics' and 'sprints' and adding difficulty scores to each feature based on a project-specific difficulty rating systems often felt like too much for what I was trying to do.

I wanted something that would let me use a user-centric and continuous delivery approach but still be able to get a simple list of feature requests in order of priority and get started without other methodology overhead.

I wanted to stash ideas separately

Most alternatives ask you to create bug, issue or story as the way to capture a feature or some other task needing to be done in the application. But sometimes I only want to capture an idea, or half-idea, without it making its way into the list of pending features. 

Maybe I am not going to persist with the idea, or I just wanted to capture half a thought quickly while it occurred to me, but it will completely transform when I come back to work on it later. What might ultimately become the next breakthrough feature usually starts as a very rough idea, and can even be very different from how it ends up looking. 

It feels right to capture these ideas in the same application that the rest of the product planning and management is taking place, but to me, we must separate ideas from the main list of features we want to work on. This ensures they don't start working their way into project planning even when they might still be vague, unexplored, and maybe not even something we will decide to push through with.

I wanted to be able to capture ideas and associate them with a product, but also make sure they were kept separate from other activities.

I wanted to capture specific requirements

Detailed specifications and requirements are not always looked upon favorably in today's world of agile methodology. However, I believe this sentiment belongs specifically with writing the specs for an entire app before starting, prescribing specific solutions instead of outcomes, or worst of all creating immovable signed-off specs with no facility to make changes as you learn. 

I think it is incredibly helpful to clearly understand what outcomes you are trying to achieve before you start coding a feature - and that's what I mean by a spec. 

It is ok to be specific about the goals of a feature, why you are doing it, who you are doing it for, and what are the main requirements or outcomes you want to achieve. I believe it is only being specific about the exact solution prior to design/development that the agile-world would take exception. 

There is still room for specifications in modern programming, but an outcome-based approach with more room to experiment in the solution itself is how we can stay on track whilst best delivering for our users.

I wanted to be able to capture the usual 'body' or 'background' field on the spec, but I also wanted a way, when the time was right, to be able to document and capture a specific list of requirements or outcomes. Rather than being hidden in the description, I wanted to be sure these could be extracted and listed separately. I also wanted a way to check them off as I confirmed a new feature or solution had covered them.

I wanted guidance on creating a real product strategy

Previously I have kept product strategies partly in different brainstorming notes, and partly just in my head. As I studied and learned more about it last year, I became aware of how important and how useful it is to have a documented strategy all in one place that you can easily share, and keep pointing to and looking to as a reference in decision making.

And a real product strategy is not just a vision, cute tagline or goal, it is a more in-depth exploration of who you are building for, what progress they are trying to make, what problems you are going to solve for them - and why they should pay you money for that solution. 

I wanted a way to capture these kinds of questions and challenge me to answer them in the application as I defined a new product. It can be painful and challenging to work through, but what results is a powerful document that you can use to share and validate your idea, but also to reference and stay clear on your mission as the feature requests come in.

I wanted my product strategy connected to my features 

My passion for product strategy quickly led to identifying the need to link each feature to it. It is no good having a strategy done once and filed away, and then continuing with whichever features sound fun to work on. 

I wanted something to challenge me to consider how each feature aligned with the strategy. Which of the application's user roles will be served by this feature? Are they going to be excited by this? Which of the problems we set out to solve does this feature address? Does it even serve the users at all? Or is it an internal refactor or upgrade that we find interesting? And if it is, is now the time to be working on it?

I wanted to see the whole project summarized in one dashboard

I love reporting and dashboards and the way they quickly get you what you need to know from a large data set. I especially like live dashboards, where you can kick back with your browser on full screen and watch them update as the data changes. Gone are the days of the F5 refresh. You can tell I am a Six Sigma person that has been hanging around contact centers! 

Surprisingly though, I did not find too much in the dashboard space in alternatives I looked at. They would have very methodology specific charts like agile burndown charts etc., but even those were one-to-a-page, so I could never find a single view to give me an overview.

I wanted to create a single dashboard that could instantly answer all my burning questions about a project. How many specs are open? Closed? Are there any bug reports outstanding? Which release or milestone are we currently working on? What is our progress on that? What is the current mix of features, bugs and internal optimizations? Are we focused in the right place and doing enough for the users?

Conclusion

And so we made SpecFuse!

We have been using SpecFuse for six months - both for building SpecFuse itself and working on some other products we have coming up. I am really enjoying the experience and the way it is helping me to manage these products. It has helped me capture clear product strategies and then keep things moving in that direction. Being a user of the application itself has helped bring lots of updates and enhancements over the last few months.

Since we made SpecFuse available publicly we've had users from around the world join and begin managing their upcoming products with us. It has been very energizing to get their feedback and learn that there is a broader interest in this product. 

We are looking forward to helping people bring some amazing products to life. We are right here with you building new products as well, and we'll continue to update and expand SpecFuse to support all our needs as we all push forward.