Developing personas is a light and effective way to determine needs whether it be usability, interface, or actual function. If you imagine Kristine the HR manager and what she wants to do, find and accomplish – you can determine a great deal. Kristine doesn’t need to want to conduct her whole life in your interface – just her job title and whatever she loses sleep over. If you have a few of these personas, you’ll get the vast majority covered; especially if you’ve been disciplined enough not to set out to build the everything of everythings.
You gotta decide what you are going to be for whom. You don’t want to be anything “in general” nor do you want to be everything to anybody. No one wants one thing to be everything so pick a lane and stay in it. If you have competition – that’s a good sign. Competition means there’s a need. If you don’t you either talking about it differently (which might be good, or not) or the market hasn’t decided it needs you – that’s bad.
Since you’ve now realized competition is good to find out what yours is doing. But first, make sure the competition you think you have is indeed the one you have. Who else is appearing on a prospects shortlist? Who else is at the final cut with a proposal? Who else comes up in the searches? Who else is buying those keywords? Remember the biggest competition is often “do nothing,” or it’s close cousin “make who or whatever we have work.” If more of your market is doing nothing note that you are going to have an uphill battle because this means, at its heart, the problem isn’t big enough to spend money. I don’t have to tell you that that is not good. If you’ve looked yourself in the mirror and made peace with all this and determined that you aren’t the very first to a non-existant market and that the market is spending money on the solution this problem – look at how the competition is positioned and what they are offering. Determine whether the same features benefit your prospects and why. Note approaches that are the same and distinguishing characteristics.
Wireframes are the plain brown wrapper of software products. Build one for every screen and pop up – do it for desktop, mobile and tablet. This might seem tedious or inessential but giving the implementation team clear instruction limits the errors in interpretation, and that reduces waste of time and resources. If you can tighten up the deliverables, then you can get closer to your goals, delivery dates, and roadmap predictions. IN other words – don’t be lazy – do what you can do. Every little bit helps.
Don’t expect developers or data engineers to “figure out” where a piece of data is coming from. Spell. It. Out. Or have them spell it out and CHECK IT. Developing software is expensive and time-consuming. You don’t have oodles of either – and if you have enough to waste you deserve to have it wasted. So – spell out the data, make sure everyone knows where the data goes, what it is, and where it comes from. Guessing and mysteries are the enemies of progress.
Develop a roadmap. Make it detailed. You may only know the first “phase” or the initial screens but develop the roadmap that leads to that place as well as to the parts that are connected to those places. Eventually, the roadmap devolves into a compass for later iterations. That’s fine. Build the roadmap for short-term features – essentials and the compass for the stuff that’ll come later and when you get to later – put all that stuff on your roadmap. You’ll get more experience, and the experience will make you better at understanding the pace of things, the likelihood of going over, and how you’ll need to fudge timelines to make things work. But you have to work at it. Roadmaps are not an event; they are practice. You must constantly check in after a deliverable and feedback into the process to get better and better at it. Roadmaps are a learning journey – learn from them.
Budgets – whether they are expressed in time or money – are important. If you plan to spend $20 on building something that will take weeks, then you aren’t valuing the time or the feature. Don’t overburden development or implementation staff. 20-25 deliverable hours is really all that can reasonably happen in a week. Why? Because people have to pee and eat lunch and log their hours. They have to think and plan and discuss solutions – so that 20-25 is 30-35. Seeing that time as unproductive is counter-productive and unrealistic. Let your staff know how long you expect a feature to take. Let them weigh in. If you think 10 hours and they think 30 there’s something that accounts for the disparity. The more you work through those things, the better you will be – so work through them – you want to be better.
Software product development is complicated and much more than some smart engineers and a business manager. If you want your product to get built and live beyond beta – take the time to build the pieces that make the chances of success possible.