It is the end of the month, Friday evening 7:30 pm. The financial department has sent you back the spreadsheet for the developer’s time logs to correct it. They’ve observed that some days don’t have the correct logged hours even though you’ve went through the whole document multiple times before sending it.
The project’s time logging process is a tedious affair, one that requires each developer to log their time on multiple platforms, and your job as a Project Manager is to retrieve them at the end of each month to be sent for billing.
As straight-forward as it sounds, the reality is completely different. You are managing a project that has 20 developers allocated to it and for the past 6 months, it has been a recurrent theme for the document to be sent back to you for corrections. It’s incredibly frustrating, you feel like Sisyphus pushing a rock to the top of the mountain, only for it to fall back again. Nevertheless, you finish your work, pack your things, close the office, and head home.
The problem is lingering in your mind. On your way home, this is the only thing that you can think of. You try and imagine other things, but just like your shadow, it never leaves your side. “It’s nerve racking!” you tell yourself “If only there was a way to solve this issue.”. You pull out your phone and start searching for an application that solves what you are facing. Unfortunately, to no avail. Not even the second page of Google could help you.
You get home and you hit the shower. You turn on the hot water and put yourself under it. While the hot water is dripping and you are feeling every drop of it hitting your body, it strikes you. “Eureka!” you shout enthusiastically, “I have found a solution!”. Finally! The moment has come. The problem that was lingering in your mind through the duration of your commute is solved! The solution you came up with is a platform that has end to end integration between the time logging platforms and the financial department.
Once out of the shower you go and note your idea. When you start noting, the excitement starts waning, and reality starts hitting. You suddenly find yourself in front of a wall too high to climb. You ask yourself, “Well, I am not a technical person nor a product person. I have worked in project management my whole life. How should I approach bringing this solution to life?”.
Do not despair! This is the normal reaction everyone has when thinking of a new idea. As a matter of fact, building a successful application, whether for internal or external use, is a tedious and risky process. At times, even with a lot of hard work and dedication, the odds will be against you. But, through careful planning, good questioning and client interviews your odds will increase significantly.
Planning
Now that you have an idea about what you are willing to create you should ask yourself whether you are the only one encountering the problem, to make sure that you aren’t solving a minor inconvenience. To clarify this dilemma, it would be wise for you to ask either company colleagues or people from other companies who also work in project management (or any other domain for instance) to make sure you are solving a real pain point.
When interviewing people, make sure you are not asking them for their opinion regarding the idea you’ve thought about. This gives people the tendency to lie to you by saying that “your idea is great!” just to not discourage you or make you feel bad about it (Recommended read: The Mom Test by Rob Fitzpatrick). Rather, ask how they go about their day, what problems they usually encounter and what drives them mad when doing their work. This will give you a greater chance to succeed with your platform because you know for a fact that you are not wasting resources in building something that the people may not want to use.
Suppose that you go around and ask your peers about their problems. While questioning them, you find out that the problem you are encountering also gives them a headache and they are proactively looking for a solution to this problem.
That’s some fantastic news! You’ve found what in business we usually call a “product-market-fit”. This generally means you are off to a good start and that the future of the product seems promising.
Dream Big, Start Small
Once you’ve validated your idea with the market, the next step would be to think about what the main application flows are that you’d like to achieve. I know, I know. You are excited; you want the application to be able to do everything, you want it to have all the features possible, and be as complete as possible.
This is great news! It means you are deeply passionate about what you’re building, and you completely trust that this will bring other people huge benefits. But you’ll have to be cautious. It’s important to dream big, and not just important, it is necessary to do it but at the same time, you will have to understand the significance of starting small.
By starting small I mean to think about the most necessary features that would make the application fully functional and valuable to the problem you are trying to solve. For this, I recommend using the MoSCoW framework (What is MoSCoW Prioritization? | Overview of the MoSCoW Method (productplan.com)) and try to focus on delivering the musts for the first iteration of the platform. It is of utmost importance to deliver a qualitative application in the shortest span of time possible to see how it fairs in the market. (Recommended readings: The Lean Startup by Eric Reis and Build by Tony Fadell).
Therefore, you start researching your application flows in order to define them. After talking to other Project Managers, you find out that the biggest problem PMs are having is extracting time logs from Jira. So, you put it as the most important flow for your application. To achieve this, you would need to integrate with Jira, take the time logs from the tickets solved by the developers, and show them into the application to be validated by the PM. Once validated, they can be sent via email in an excel format to the financial department.
With the main flow decided upon, which represents the selling point of your application, you’ll also have to think of other secondary but important flows as they are a prerequisite for what you’re building. Those flows include user authentication, password reset, email sending, profile management, etc.
That’s it! Your application’s first iteration (aka MVP) shouldn’t be more complex than this. You have defined what is the most prominent pain point the people are encountering and the one that is the most important to solve.
Still, you may be in doubt to launch your application as such because you are finding it incomplete. You’ll look at other applications and say, “well others have a ton of features, wouldn’t people find my application very barebones?”. A very legitimate concern but, let me tell you a story about the first iPhone.
When it launched back in 2007, it was a revolutionary product which lacked a lot features that people were very used to in other mobile phones. For example, the device didn’t have video recording, a copy-paste functionality nor the ability to move the apps on your screen. Hell, you couldn’t even change the background, and you were stuck with a black image on your home screen. Also, the App Store? That wasn’t even a thing back then.
However, features weren’t the point of iPhone, and Apple knew this perfectly. Through iPhone, they wanted to solve a bigger problem, one that other mobile phone makers couldn’t do. Which is to make the phone as accessible and as easy to use as possible. They wanted to make a device clear and simple, so simple in fact, a two-year-old would understand how it works. And this was the reason why the iPhone became the household name we currently know. It wasn’t for the features, it was for the one main problem Apple has managed to solve, which is mobile phone accessibility.
Rule of Thumb: Use the same approach as the iPhone with whatever you are building. Find a real and annoying problem and in the first iteration, solve that one problem only, but solve it better than anyone else in the market. Once the application is published, you can think about adding other features and nice to haves that your users are going to appreciate.
Define your Tasks
Once you’ve defined the main flows, the next step would be for you to write the tasks that are needed in order to fulfil your vision. To be able to achieve this feat, you need to take your flows and divide them into smaller pieces that can be used to create the first set of tasks. A good approach would be to use the User Stories concept from the Agile methodology. (User Stories | Examples and Template | Atlassian).
Let’s take for example the flow of integrating Jira into the application. An example using Agile User Story approach will make it look something like this:
Story: As a Project Manager I would like to integrate with Jira so that I can see all the time logs in a single dashboard
Acceptance Criteria:
- When clicking on sync with Jira Button then all the time logs of a certain project from Jira should be visible
- When accessing the dashboard then, all the time logs should be inserted in a table
- When clicking on the download button then the table would be downloaded in an excel format
Another example of a task for user authentication would be as such:
Story: As a Project Manager I would like to authenticate myself in the platform so that I can see the time-logs in the application
Acceptance Criteria:
- When entering the details correctly then the user should be redirected to the application
- When entering an inexistent email, the user should receive an error message saying that the email doesn’t exist
- When entering a wrong password, the user should receive an error message saying that the password doesn’t exist
Rule of Thumb: While you may be worried that you won’t be able to think of all the tasks possible, this shouldn’t be a problem for the time being. The idea of this exercise would be to give you a good overview of what should be the point of focus that needs to be done in the subsequent Design & Prototype phase as well as having a solid starting point for defining the final list of tasks before development kick-off.
Design & Prototype
Until this point, you have achieved a lot. You have interviewed people, validated the problem, decided on the main flows, and also created the first set of tasks. Phew! That’s a lot done; you should be proud of yourself because it will ease up your work from this point on. Even though what’s coming next is not easy per se but, having a clear vision of what you want to achieve will help anyone work in the most efficient matter possible.
So now the next step after defining the tasks is to define the user experience. By that I mean, how the user is going to interact with your application and whether the interface you are building is clear and straightforward enough for anyone to get ahold of it. For this to be an achievable feat, you have to start with what is known in the design industry as wireframes.
Wireframes
Wireframes represent the skeleton of your application on top of which the visuals will be built. They help you visualize the structure of it before any code or color is put on top of the interface. Their purpose is to make it easier for you to iterate the design based on the feedback received from the people testing it. Also, they are essential in building an easy to understand and easy to grasp user interface. So, take your time when designing the wireframe as this is going to be the backbone upon which your front-end application rests. (What are wireframes and why are they used? | Wireframing Academy | Balsamiq).
Design
Once the wireframes are completed the next step would be to add the colors and designs necessary to make your application look like a finished piece of software art. At this step, the designers, depending on the requirements specified by you, will propose multiple directions from which one will be chosen.
For this step to be concluded successfully, it is very important to know your audience well and to factor in what are the most important things they look for in an application, as well as where they may be spending most of their time in the application, in order to create a seamless experience from login to logout.
Also, you must take into account the parts of the world you are targeting in order to know what type of design direction you have to take. For example, the western world is usually used to minimalist straightforward designs that are as clutter free as possible. They like things that can be learned after 5 minutes of using the application. As for the east Asian part of the world, the concept of a good design is radically different. For our tastes in the western world, it can be considered cluttered with information we may not need at all and so, may not find it attractive per se. This also applies vice-versa.
Testing
From the moment you start designing the wireframes, testing should be taken as a priority if a good user experience is the needed outcome. To make this achievable, discuss with your team to make the design interactive so that the results of interviewing other people that benefit from your solution would be as accurate as possible.
When interviewing people for the design, observe their reaction very well. See what parts they are interacting with and, what behaviors they are evoking when playing with your platform’s design. It’s important to not intervene or try to help the user when they are stuck at one point, this should give you a signal that something is not done right and should be noted in order to get fixed.
Also, avoid as many questions as possible that puts your ego forward. Remember, you are creating an application that wants to solve a problem. It’s not about you, it’s about the end-user thus, try to avoid questions such as “Do you like the application?” or “Would you use something like this?”. Instead focus on asking questions that bring you value, here are some important things to consider when interviewing:
- Introduce the prototype and remind the user to provide candid feedback, i.e. “I did not design this product. Nothing you say will flatter me or hurt my feelings. I am interested in what you are experiencing today.”
- Follow up about the task. Ask questions like: “What were you expecting to happen?” or “What would you do next?”
- Debrief by reiterating some of the insights you have observed during the interview. Ask things like: “How would you describe this to a friend?”, “Who is this for?”, or “What would you change about the experience today?
Building the Real Thing
I know what you’re thinking of “Why haven’t we started development yet? Why does the process take that long?”. That’s a very legitimate question and I completely understand your concern but, as I mentioned in the intro, building a software product is a tough business. In order to build something successful, you have to try and maximize your chances as much as possible through the process of interviewing, prototyping, implementing and iterating.
Following this process aids you in finding out whether what you are building is a viable idea or not and whether it is worth continuing or if it’s better to pull the plug. Knowing when and how to quit is an important skill that saves you a lot of time, money, and effort.
However, we’ve went through the process already, we know that our idea has product-market-fit, and it really solves a real problem so, our next step would be to build the solution in order to publish it. How could this be achievable?
Well, there are numerous solutions we can think of and multiple ways to bring our vision to life. I am going to mention the 3 main solutions you can use in order to make your idea a reality.
Internal Development Team
If you are lucky enough and you are working in a company that already has a development team then, that’s great news! But it comes with its set of hardships also. In order to be able to build your application with the internal team’s effort you’ll have to do a lot of talking and convincing so the directors would accept the budget to construct your vision and that may take a bit of time.
In the happy case where you are a founder/decision maker in a company that has an internal development team then that would make matters easier as you’d have no convincing to do and only have to check your team’s availability and whether you have enough budget to start working on the project (maybe a bit more difficult than this but, you get the point :D). A better solution that helps in saving you a lot of headaches would be to hire an external development team.
External Development Team (Outsourcing)
Requesting an internal development team to build a project may be the more complicated thing to do. There may be cases that even with an internal team, you may not have enough people to put on the project therefore, this would require you to either hire people for your project or take productive members out of their roles in order to work on the project. Both cases are not ideal and can bring a big overhead to your day-to-day operations. Thus, hiring an external team, can help you mitigate those issues.
Even though you may think that this choice is more expensive but, think about the advantages it comes with. You don’t have to manage a team of developers, project managers, business analysts and designers thus, your operational and time costs are going to be much lower in the long run. Besides, you are going to have a team of experts with whom you could consult on every technical matter and in case something new appears that isn’t in your internal team’s area of expertise, the external team would be more efficient in adapting, saving you the headaches of finding a capable person to get the job done.
Low Code/No Code
Have you ever thought about the possibility of you helping to build the product? Yes, I am not exaggerating. Low Code/No Code solutions, especially when building the front-end, require minimum to no code intervention whatsoever. And with a bit of a learning effort, you will be able to build the front-end application.
Also, a low code/no code platform will make it faster, cheaper, and easier to develop your application while enabling you to iterate as quickly as possible.
However, it’s important to emphasize the fact that using Low Code/No Code won’t rid you of technical skills, especially when you consider the application’s back-end. If you don’t have the necessary technical skills, either find someone who can help you or, contact a third-party development company to help you fill the technical deficiency.
At the end of the day there is no wrong or right solution, only a solution that fits your needs. Also, consider mixing and matching the solutions. In some cases, you may have an internal development team and they come across a challenge that requires either consultancy or extra muscles. In that case, don’t hesitate to contact a third-party development company that can offer you an augmented team that compliments the team’s need and experience.
Conclusion
Having an idea is just the tip of the iceberg. The difficulty occurs when you try to successfully bring your idea to life. Be efficient in the planning phase, come up with a plan to interview and discuss with as many people as possible in the shortest amount of time possible, find common pain points and try to come up with a solution for them. By taking the scientific approach, you maximize your chances of success while also lowering the risks of building something the market will not need. And most importantly, it will show you if it’s worth continuing what you are building, saving you time, money, and effort.
How can Devista help?
At Devista, we offer a discovery workshop that will help you with the process of building your idea. We help you with defining your main flows, detailing the tasks, and creating a medium-fidelity design prototype. At the end of the workshop, you will receive a document containing all the previously discussed points which you will be able to use in the interview process and see whether your idea is viable.
Once the workshop is completed, Devista can help you with putting together a team of developers that will act as your technical team helping you achieve your application’s vision.
If you’re hesitant and not sure whether we can help, feel free to get in touch anyway by filling in the contact form so we can discuss and find out. After submitting the form, we will get back to you to arrange a no-strings-attached Discovery Call to discuss your challenges and objectives and determine if we are the right people to help.
Recommended Readings
The Mom Test by Rob Fitzpatrick: The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you: Fitzpatrick, Rob: 9781492180746: Amazon.com: Books
The Lean Startup by Eric Reis: The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses: Ries, Eric: 9780307887894: Amazon.com: Books
Build by Tony Fadell: Amazon.com: Build: An Unorthodox Guide to Making Things Worth Making: 9780063046061: Fadell, Tony: Books
