When using their favorite apps, not many users think about those working behind the scenes to create them: Managers, developers, designers, and many others who transform ideas into real-life digital products.

There used to be a time when a Project Manager was all the leadership a software product required in its lifespan.

But it takes a whole other set of skills to deliver a competitive product to this market.

As technological advancements reached new heights and users embraced them wholeheartedly, the market expanded furiously. New competitors emerged, and remaining ahead of the game became more challenging than ever.

Users don’t ever need to settle with a mediocre experience – there’s always a new option readily available around the corner. In such an environment, there is no room for an average product.

Previously, such projects only used to take a developer or two and a Project Manager.

As the focus shifted to creating competitive products, “project” started to refer to the organizational surroundings required to create that product. The product part got a life of its own, and the user all the attention his needs and experience deserve.

Along the new management roles emerged from the need to carry out the variety of activities and specialties now required to get the show on the road.

Getting the product launched is just one destination reached. The real journey begins from that point onwards.

Iterative development, more commonly hidden behind the term agile, is how most successful companies choose to travel the road.

This enables product decisions to be driven by real-life data and insights and keeps the product on the path that will bring actual value.

With the agile way, the product also becomes more flexible to the changes in the market: Inspecting the current product version and adapting to the new findings in the next can provide a great deal of competitive advantage, both instantly and in the long run.

A release does not necessarily have to be big, complex, and packed with features to be valuable.

In fact, planning the product is more flexible, as it doesn’t require the business to have all the answers at the beginning, but enables the product to grow and evolve over time.

The return on each decision for investing development efforts can be effectively tracked and measured. If the desired results are not met, each new iteration represents a new opportunity to get back on track.

With the Agile way, a product is allowed to attempt a lot, win sometimes, fail sometimes, but learn from each, to win even bigger next time.

Sometimes, a client will bring in the exact vision and execution plan.

A Project Manager will then assemble a skilled crew that can create the product as specified, keeping track of the production to get everything polished within the planned budget and deadlines.

Other times, the client will have a high-level brief of the product they desire but won’t necessarily know how it should be done.

In between the two cases, there’s a myriad of other possibilities. Even with a plan laid out perfectly, the product still might encounter unexpected challenges.

A reliable vendor must be able to scale their purpose for the project; fit the needs of the departments they’ll be cooperating with; fill the roles that are missing, and be a helping hand whenever the client needs one.

The Product Owner role may strike as ambiguous at first. In an agency environment, executive decision-making always remains in the client’s hands.

We do not lead your business: We navigate the team and provide technical guidance towards achieving your business goals (beers, too).

Some clients wish to remain fully in the director’s chair, working closely with the development and design teams.

In that case, the client provides product research, vision, and roadmap in the form of planning and delivery strategy.

The client is then also responsible for defining and writing feature requirements on a daily basis, participating in creative decisions to define the look and feel of the product, prioritization, and all other preparations of the work for development.

Alternatively, the client might choose to only be involved at the high level. That’s when the Product Owner takes on all the day-to-day heavy lifting, all along keeping in constant sync with the client to ensure they’re on the shared path every step of the way.

During development, the Product Owner will also help the team prepare frequent product demonstrations for the client to review the progress and provide feedback, so nothing unexpected pops up once the final cut is ready.

When projects and products grow in complexity, the two streams might be divided between two experts – one a Project Manager, another a Product Owner.

At times, you hear even a third name mentioned.

An Agile environment might require another role, not formally placed in the management but equally involved in the project, product, and the team – a Scrum Master.

This role’s main focus is supporting the managers to define a successful product, the development team to build it, good engineering practices, nurturing the culture of innovation, and striving towards continuous improvement.

Not for the purpose of imposing the need for perfection, but to create an environment where teams can learn, thrive, and advance.

Good developers and a talented Product Owner don’t put 5-star reviews in your pocket. It takes the whole team, and the Scrum Master is what supports the crew in becoming that winning team.

When our and client’s developers, managers, or designers are collaborating on the product, the Scrum Master also works on bringing them together, to work as one cohesive team instead of taking any sides.

All said and done, the management team has its work cut out for them in today’s world of creating software products.

Imagine all these responsibilities landing in just one pair of hands, with only a set of traditionally-cut project management practices.

Probably doable, but it certainly won’t get you the winning product.

If you’ve ever read a fairy tale, you’re probably familiar with the concept of the fairy godmother. These magical beings materialize during tough times and bring good fortune to the story’s hero or heroine. But did you know fairy godmothers have a lot in common with quality assurance teams?

Until now, you’ve probably thought of QA in terms of exhaustive testing and meticulous attempts to break apps. But here at Infinum, our QA team consists of versatile, curious people who don’t let any part of the project fly under the radar. We become the project’s shadow that never leaves its side.

Some characters also need a bit more attention and care to shine, when good fortune runs out. In other words, QA becomes their fairy godmother.

Ready to work your QA magic? Here are ten practices to help you shield your project from harm and ensure that it lives happily ever after:

Once upon a time, there was a project. This project’s development time was estimated without even the design draft. After a while, the estimates were changed again and again, which made the project manager very unhappy. The designer was also sad. If he had been there, he could have helped estimate a more accurate time needed for development. But with the existing estimates, everything had to be rushed and changed on-the-go. With such little time, QA struggled to keep the project on track. They were already past the point of no return.

This disaster could have been easily avoided. The cursed team in this scenario forgot one basic rule: the planning and estimate phase serves as the foundation of any project. It’s critical to include the designer when creating time estimates – that allows everyone to agree on the optimal solution together, instead of having to go back and forth later.

In the prototyping phase, there are countless screens, states, flows and invisible micro-interactions. Therefore, a developer, PM, client or QA looking at the design could easily miss a critical element or misinterpret something. If any detail is unclear, it’s very difficult to discuss it, let alone identify or repair the problem. All of this can potentially lead to a wrong implementation, big design reviews, misunderstandings and other delays.

Remember, the designer knows his work best—which is why he should be the one interpreting it to other teammates. If face-to-face communication isn’t possible during the prototyping phase, discussions via Zeplin and InVision could be helpful.

In many cases, project deadlines or an agile project methodology requires fast development of smaller bits of an app. Under these conditions, development sometimes starts before the final design is approved.

That causes on-the-go changes, which are often poorly documented, hastily executed and require a lot of additional polishing to achieve the intended quality. This is hardly avoidable, but you should aim to do best with what you have – track which changes have to be made, why they are being made, question and discuss them, and make sure that they are implemented correctly whenever they have to be done.

The ideal solution? Do not start implementing anything until the design is finalized. By slowing down at the beginning of a project, you’ll save loads of time on the back-end. If you take the waterfall approach, it’s critical to ensure your design is ready in time. If you work agile, you can iterate design, but at some point, you should polish the feature and move on to the next one. Last but not least, it’s critical to set priorities for the entire team.

Zeplin is an extremely useful tool that includes the most technical information needed for implementing a feature according to the design. However, this tool should never be used in place of a team meeting with the designer. It’s worth repeating: The designer knows his work best.

Misunderstandings lead to mistakes, delays, and lower quality. Therefore, when the time comes to hand over design for implementation, it’s critical to hold a meeting that includes the entire team. This ensures everyone is up-to-date with current events and informed about all project details. During this meeting, the designer can provide further clarification and answer questions on the spot.

We all know there’s a huge gap between designers and developers—and not just in their professions. Whether it’s the way they approach a project, their interests or favorite ice cream flavor, designers and developers are often polar opposites. Despite their differences, they have to work together. That’s where you can jump in.

As QA, your role is to serve as the middleman between the designer and developer. Encourage both sides to learn from each other and make each other’s job easier. The key is to make sure they are communicating. Which brings us to our next tip…

Without developer-designer collaboration, implementation is kind of like shooting at a minuscule bull’s eye on a small target from a long distance…in the dark. If you’re skilled, you probably won’t miss the target completely. But why risk it? This is where good communication is key. Help them translate technical and design terms to each other until they become comfortable with the basic terminology. This will allow the team to solve problems efficiently and keep the project on track.

By fostering communication and collaboration between the designer, developer and the rest of the team, your project is set to be a booming success.

There will always be iterations in every project. Some big, some small, but changes are a fact of life.

At this stage, quite a few people are actively included in the project: designer, developers, QA, project manager, the client, and others. When any change occurs, all concerned parties should be properly informed.

Writing “@here” on a Slack channel does not qualify for “informed properly.” If the design changes, it’s important to update Zeplin and provide links to those screens where needed. It’s also vital to make sure that the project documentation isn’t scattered around and is always up-to-date. As QA, you should be aware of all changes and follow-up to make sure these updates are made.

In real life, users won’t be using software with dummy data. You’re not doing your designers any favors by using random test inputs. This is why it’s important to test out how the app will appear to the real user with real content in real situations. Sure, it will take more time, but your designer will be grateful and your product will be better.

Sometimes the app will be used in another language, in which the appearance could be significantly different. In this case, the UI issues could occur only with real data simulation. You won’t know if you don’t test it. So, don’t leave this one to chance. Use real data simulation when testing.

Prototype and implementation are never the same. This is why it’s important to conduct user testing with the “real thing” while implementing. Plus, this practice will provide valuable feedback for everyone involved. The designer can see his meticulously designed user experience in action; the QA can focus on the real user’s behavior, needs and expectations; and the developer can witness a custom UI element paying off, making all those long working hours totally worth it.

This process can also indicate if any further effort, changes or improvements would be worthwhile.

Of course, any conscientious tester will ensure the design is implemented properly and UI/UX are truly high quality. Even so, the designer should always have an opportunity to test any UI/UX-related tasks after implementation. That way, the need for big design reviews will be reduced, since most issues would be discovered and mended during this process. This is yet another way to ensure designers are included in the development process.

It’s important to work your magic throughout the project and to be the true fairy godmother to your teammates when they need you. If you follow these practices, your project is certain to live happily after ever.