We’re not sure of dates or timelines on any of the following features or ideas, but since we’re really excited, I wanted to make sure that we’re open about what’s going on behind the scenes.
Client Work
For the immediate future (the next few weeks), the reality is that I’ll be spending the majority of my time doing client work to pay the bills. While that means that things will be relatively quiet on the Sifter front, we’re in the process of designing and prototyping some significant new features.
The more exciting news is that Sifter is getting every closer to supporting me full-time, and when that happens in the next month or two, the sky’s the limit. In the meantime, though, we’re having to be very mindful of how we spend our time.
How We Approach Features
Building software for the long haul isn’t trivial. We spend significant amounts of time refactoring and improving code, designing and prototyping new features, and exploring new ideas to see how we can make Sifter great. The things we learn along the way invariably have an impact on our decisions.
It’s a Marathon, not a Sprint
We will never rush features out the door just to get something in your hands. We’d love to crank out features overnight on request, but we’re trying to be much more prudent about that. As a result, it takes longer for us to settle on what we believe is the right design and implementation. We like to release features when they’re ready instead of focusing on a deadline. If we seem unresponsive with new features, it’s not about neglect. In fact, it’s quite the opposite. It’s about being cautious and thoughtful about the impact of our decisions.
Learning and Adapating
We spend most of our time designing and prototyping features. As a result, we often learn that while those features sound great on paper, Sifter isn’t really ready for them. This makes it tough because we want to be as open and transparent as possible, but our priorities are constantly in flux as we gather additional information and learn how new features will interact with existing features as well as planned upcoming features.
Our Vision for Upcoming Features
It’s easy to talk about “email” as a feature. It’s one word, so it sounds really simple. Unfortunately, like implementing search, there are a lot of moving parts. However, that’s the easy part. Our biggest challenge with email is enabling a simple, intuitive, and natural way to do more than deliver text updates. How do you update status, priority, category, or assignee via email?
We think priority and assignee should be straightforward, but status is the most important, and we haven’t thought of a way to update status via email that we’re satisfied with.
We have some ideas, and we’ve spent some time exploring them, but we didn’t want to invest a significant amount of time creating a crippled feature as a supplementary interface. Email, while important in our long-term vision, wouldn’t be enabling capabilities that couldn’t already be performed. So, it’s on the back burner for now.
Help Desk
The single biggest point of confusion with Sifter is that many people see a bug tracker and help desk as interchangeable, and Sifter isn’t a help desk. Help desks are public facing whereas bug trackers are for internal teams.
We’ve known that we want, to some degree, to add functionality to Sifter to support some of the common help desk tasks. We need this ourselves to manage Sifter’s growing customer base. This has actually become one of our top priorities for several reasons.
First and foremost, a significant portion of feature requests are indirectly related to or based on the assumption that Sifter works as a help desk. The truth is that since it wasn’t designed to be a help desk, those features couldn’t be added in a reasonable way. It also means that there are a significant amount of people out there that like Sifter, but can’t use it because it’s not a help desk. Or, they have to awkwardly concoct a workaround within Sifter. That’s no good for anybody.
Additionally, if we release the other features before we add this, many people will be using Sifter in unusual ways in an effort to shoehorn it into being a help desk that would make it difficult to transition to this feature and use Sifter in a more sustainable fashion.
The one caveat with the help desk is that we are planning on treating it as an optional for-pay feature. It won’t be a stand-alone product as it will be tightly integrated and reliant upon the bug and issue tracking portion of Sifter, but because it’s almost a separate product.
A significant majority of our customers are consulting companies that have no need for a help desk. This makes sense because that was the exact group Sifter initially set out to help. So, after thinking through many different options, treating the help desk portion of Sifter as a for-pay add-on was the best way to support product companies without pushing what will essentially be a new product on our existing customers that have no need for it.
Sifter’s origins were based on my experience and desires from years of consulting, but, since we’re a product company, we’ve become acutely aware of Sifter’s shortcoming for managing a public-facing product. This is a feature we’re dying to have ourselves, and we’re really excited about it.
Milestones, Categories, and Tagging
We’ve spent an absurd amount of time thinking about solutions for milestones. We’ve also been giving serious consideration to migrating from a single category model to tagging. Ultimately, the solution to all of these will be inter-twined. They present very similar challenges and the problems share several important attributes. However, the most important factor is that this is something where we’re feeling the pain ourselves. We want to make this happen, but we want to do it right.
API
The final major feature on our radar is the API. It’s important to us on many levels, but we also don’t want to rush an API out the door just before we make sweeping changes to the foundation of Sifter. With the API, there’s also the aspect of documentation. Just like we wouldn’t want to release a crippled feature, the documentation will be a significant piece of the API, and we want to make sure we have a good place to put it and that it’s designed in a useful and usable manner. That leads to the next “feature” that we’re working on.
NextUpdate.com
This site was designed and created before we launched Sifter. We didn’t even have a name or a domain for Sifter. The site worked, but we’ve outgrown it now that we have a working public application. Our vision is to continue sharing design decisions behind Sifter and, in most cases, share the design ideas before we’ve even built the features so that everyone can share their thoughts and offer feedback.
Unfortunately, the current design and content management solution don’t come close to the vision that we have for it. We need a place for a status blog and a wiki for API documentation and common support questions among other things. We’ve finished the design and wireframes for the redesign, but we’re focusing on Sifter for now.
Long-term, we see NextUpdate.com and the blog as one of the most important things we do. Sifter started by sharing some comps and ideas, and it worked really well. We’d like nothing more than to get back to sharing comps ahead of time and refining our ideas with your feedback before we push them out to the world.
Summary
We’re burning the midnight oil. Between SXSW and client work, we haven’t pushed any significant new feature updates in several weeks, but we’re working hard on getting these features out the door and making sure they’re well done. It’s scary sharing information like this knowing full well that things can and will change and adapt as the process continues, but we’d rather share our plans openly than leave everyone in the dark.