We are looking for Sales specialist

Who are we?

Puzzle Software is a team of passionate and dedicated IT and Agile professionals devoted to deliver excellence in software solutions and services. We provide custom software development services, our teams also work on several start-up projects, developing solutions for our clients, adjusted to their needs.

We change the world and create virtual worlds not only for the clients, because we work on our own projects, startups created by Puzzle Software.

Another tool that we also use to improve software industry and digital products is Agile education and certification, with customized coaching and mentoring programs.

After 14 successful years we would like to boost our projects, nurturing our relations with trusted partners as well as with our great consultants.

That’s why we need a superhero – you!

• You are a people person who can meet new acquaintances anywhere – the office, a local café, or at a professional conference.
• You will anticipate what’s important to the people around you and pleasantly surprise them with a solution.
• You are willing to do something nice for others without expecting something in return.
• Most importantly, you are a person of integrity.

We imagine you as an ambitious and established person, with the entrepreneurial spirit. You should be a graduate from Faculty or have a bachelor’s degree in relevant subject.

Speaking about skills, especially soft, it will be of crucial importance to have excellent communication and negotiation skills. Excellent time management and planning skills, with proactive and problem-solving attitude are additional asset.

By personal characteristics you should be extroverted, communicative and witty. You should have strong presentation skills, the ability to gather and process information related to market research, emerging trends and analysis of successes and failures. Fluent in English, speaking and writing.

Our team member should be a social network influencer, strong in communication with the community. From that perspective you will learn IT trends, to be in line with them, and to have strong interaction with the IT community.

Experience in IT industry with software and agile training sales would be a plus, but it’s not a deal breaker if we recognize each other’s potential.

Position details

You will work closely with our CEO and the rest of the team, to develop a growth strategy focused both on, financial gain and customer satisfaction.

Your role will be more human related, but you should conduct research to identify new Companies and customer needs. Regarding administration part, you should arrange business meetings with prospective clients and take leadership role in negotiating and execution of future agreements, same as keep records of sales, revenue, invoices etc.

You will be the face of our company in our business relations, so, you should promote the company’s values, services addressing or predicting clients’ objectives. Building strong and successful relations, you should provide trustworthy feedback and be trustful to our clients. Also, build long-term relationship with new and existing clients and stakeholders.

Why you should join?

We are aware of your value for our team and future development, so we offer a set of attractive benefits. First of all, a job in a small team released of corporate structure, with half less pressure than in a traditional sales team, and self-organization without micromanagement.

You will have amazing developing opportunities in terms of bonuses and learning, improving your career level and personal skills. Above all, an opportunity for a gain in the profit share in the outsourcing branch, Agile branch or product branch same as the ability to work with Offshore clients from USA and from Europe.

An attractive benefits’ package is part of our deal, modern workplace, friendly team and warm environment as well!

Sounds promising to you? Do not hesitate to contact us, submit your application by email jobs@puzzlesoftware.rs. We are already waiting to meet you! ✅

Product discovery, what, why, how & who?

Author: Predrag Rajković

You have a product, service, any kind of offering to customers, and you are constantly wondering how can I make it better, how to attract more users, will they like the feature that is about to be released, will they use the product as I imagined, and will they use it at all… All these questions fall in the domain of product discovery, and they are all yelling – “Invest your time in product discovery!”.

Let’s briefly set the stage. Looking at the product life cycle we can separate phases that the product goes through during its life. In general those phases could be – Idea, the initial phase where we explore problem to be solved and identify different opportunities that could lead us to achieving the goal that we have set in front of our product. Here we understand the problem which we are solving. First validation happens here, also. We are checking if our hypotheses around the problem are valid, i.e. does the problem exist for our future users and is it worth solving. Next phase would be creating potential solution, and testing through prototyping. After it, comes the phase of product creation (or development), testing and first release. Till now, our product is alive, it is getting traction, user base enlarges and we are considering new features that fuel growth of our product. Finally, as the time passes, our product enters the final phase of its life where we consider either its retirement and withdrawal from the market, or we pivot and try to give it a new life changing its focus, key selling points, problem it is solving, or target audience.

Product life cycle

 

Ok, so where is a product discovery here?

It happens in all those places where we increase our understanding of our product. It happens through different means – market research, user interviews, data analysis, feedback analysis, understanding of business goals… Therefore it might happen, and it happens in any part of the product life cycle, but we might say that it is the most intensive and crucial at the beginning of the product life.

Why crucial? Isn’t it crucial that we create and deliver a high-quality and technically superior product?

While it is important that the product we deliver is of a high quality, it is still essential that someone wishes to use it. In other words, creating the highest quality product, built using the latest achievements of technological progress, that no one wants to use is just a wasted effort. We have a spaceship, but no one wants to sail through space.
In other words, while delivery helps us build the product right (with the high quality and in an efficient way), discovery helps us build the right product (i.e. product that people want to use)…

And this is why product delivery is crucial – it is a set of activities helping us find out (discover) what our customers want and need, and helps us communicate those wishes throughout our company.

Before we jump into how we do discovery, let’s see who should be doing it. In general, you need the team to do the job well. The team should consist of people with different backgrounds. The more perspectives, the better as long as the communication can be held under control. As a rule of the thumb there should be 3-5 people as a core team engaged in discovery. Of course, it is possible and desirable to include additional subject matter experts when needed. Quite often there is a reference to 3 people accountable for the product overall and for the discovery also. They are called the 3 amigos, or the product trio. Those 3 people should come with the product management, design & UX, and engineering background.

That being said, let’s see what product discovery consists of. We might break discovery process into following activities:

1. Desk research
2. Empathizing with target user
3. Defining the opportunity space
4. Defining the desired outcome
5. Prioritizing opportunities
6. Solutioning and experimenting
7. Defining the MVP and MMP
8. The visual design

Please note that having said activities doesn’t mean that they are done linearly in successive order. Some of them are intertwined and happen iteratively.
Another thing to consider is time spent in the discovery process overall, and with it in each of these activities. There is a risk to spend too much time on a discovery. It might seem that we have never done enough analysys, that there’s always an angle or piece of information that we haven’t considered, or the stone that has not been turned. The best way to mitigate this risk, and not to reach paralysis by analysis state is to sandbox each activity. Yes, there’s a significant difference depending on the concrete product or a feature we are discovering. Some are obvious and we know a lot about them, while others are just a vague idea of what to create. But with some experience you will be able to estimate time for these activities. After all, if it turns out that you lack vital information to make a decision, you can dedicate more time to it.

1. Desk research

Typically, desk research encompasses reading different reports, studies, analysis, etc. The purpose of this phase is to collect initial information on the product you are considering, and its environment. Internet browsing is a useful way to get needed data, just be cautious of the source you are using. Currently a lot of people are using ChatGPT for this phase. Bear in mind that currently information on which ChatGPT 3 (which is available for free) is trained on, ends with 2021, which means that at the moment of writing this article (May 2023) information is already 2 years old.
Analyzing internally available data on product usage is a very important part of this research. Understanding the stickiness of our users, their behavior with our product, things they visit, where do they spend their time, what are they interested in, what do they buy, at which steps of process do they fall out, makes a cornerstone for further discovery.
During this phase we create the background picture, the scenery of our future product.

2. Empathizing with target user

If we haven’t done it before, here we have to define our target group of users, our customer segment, our user persona. We have to understand who we want to talk to, whose pains we aim to relieve.
Once we create the scenery and we know objective facts on our product and users it is time to get into the mind, into the subjective, emotional part of our users’ behavior. While in the first step, desk research we are talking mainly of quantitative methods, in this step we are predominantly using qualitative research.
In order to feel what customers feel and see our product with their eyes we include, one-to-one customer interviews, my preference goes to the unstructured interview as a format. Observation of users (or contextual observations) while they are using the product is another way. Ethnographic research could, also, be a technique of choice here.
As said, the purpose of this step is to understand our customers well, be as close to them, feel their pain. Only this will give us insight into what they need, and consequently what we should build.

3. Defining the opportunity space

In this part we investigate different opportunities laid in front of us. We are trying to identify problems customers have and formulate them in a form of the opportunity we, i.e. our product, might try to address.
Main source for opportunities is the previous step. There, we get under the skin of our customers and figure out what problems they feel. Now it’s time to reverse those problems in our opportunities and map them so that we have a visual representation. Though it might sound banal, this step is important as it is systematizing our knowledge of customers’ problems, helping us not forget some important opportunity, and, as we will see later, help us decide which opportunity we will put our effort into first.
Another important part of this phase is hypothesis testing. By listing different opportunities, we are actually embedding a lot of assumptions into our discovery. We might suppose users don’t visit our blog because they don’t find the content interesting, while the truth might be that they don’t even know our blog exists (i.e. our marketing is missing them), or vice versa. Assumptions have to be validated.

4. Defining the desired outcome

A product is a business category. This means its purpose is to bring some economic value to the company that is producing it. Therefore, none is created and led to serve itself. In order for the product management to be purposeful it has to lead the product toward fulfillment of certain goals. Therefore, we have to have clear outcomes that we want to achieve, both from the perspective of business overall, but also from the perspective of the product we are building. Put it differently, if we haven’t formulated where we want to go up to now, now is the last moment to do this.
Beware, here we formulate outcomes, meaning what we want to achieve, not outputs (which would be – what we want to build). For example, outcomes that we want to achieve as a business could be: increase our sales, or increase customer satisfaction, or increase the time our brand is in front of our customers’ eyes. Our product should serve these outcomes, or help in achieving them. Therefore, we formulate product outcomes so that they are inline with the business outcomes. Depending on our business, and role of the product in it, the outcome will be different. In other words, product outcomes will be different if we manage the single product in our company, obviously there will be a more direct relation to business outcomes, than if we manage one of the products in a company’s portfolio. Examples of product outcomes might be: increase time customers spent on our website, or increase sales via our mobile app.
I like how Teresa Torres puts it in a nutshell: “Business outcomes measure the health of the business. Product outcomes measure a change in customer behavior.”

5. Prioritizing opportunities

With outcomes defined, prioritizing becomes easier. Now we have our north star to which we are heading, and some opportunities become obvious to deprioritize. Let’s link it to the previous example. Let’s assume we are running a company website. Business goal is: Increase time potential customers are exposed to our brand. Linked with this, our product (website) goal might be: Increase time visitors spent on our website.
Also, let’s imagine we have identified following opportunities:

1. It is hard for visitors to find customer support page
2. Visitors spend little time on our pages because they are filled with text, and they don’t want to read it through
3. Visitors visit only one page because they don’t see anything interesting that they might continue reading

With our product outcome defined as above it becomes obvious that opportunity number 1 will not have a crucial impact on it. Or put it differently, the impact of opportunity 1 to our outcome would be lower than the impact of opportunities 2 and 3, meaning opportunity 1 is of a lower priority than the other two.
This doesn’t mean that we will never improve the ability of our users to find a support page. It just means that in this concrete case we have things to do that are more important for the company.

6. Solutioning and experimenting

Once we know where we will put our effort at this moment, it’s time to start working on solutions. Each opportunity can have several different solutions. Let’s assume that our top priority opportunity, i.e. opportunity for which we believe will have the biggest impact on the outcome, is opportunity number 3, visitors don’t see anything interesting to read. Here, we might have several solutions, for example: introduce a stripe with featured articles from our site, or introduce a widget showing the most read article, or create a recommended articles stripe, or make tips & tricks widget… In this step we should not only come to a solution, but also test it with end users. We don’t want to build something just based on our gut feeling. Gut feeling is ok, but should be validated in order to minimize the risk of building things that no one would use.

7. Defining the MVP and MMP

Now that we have the solution for the customer’s problem, we are considering the delivery phase, and we want to deliver the smallest meaningful set of features to our users as soon as possible. In other words, we want to define the MMP (Minimal Marketable Product) which is a very important concept. Widely used term is MVP (Minimal Viable Product), however, this term has different descriptions ranging from a literally minimal piece of code that shows that something works and that can help us prove that we can deliver something, to a product that is capable of being accepted on the market. Definition with this wide range of understanding inevitably introduces misunderstanding between product stakeholders.
In order to avoid confusion, I believe it is beneficial to separate things. Minimal Marketable Product is a set of features without which launching of the product would be meaningless. Imagine you are working on a new app for video entertainment. Here, the bar has already been set high by players like Youtube, Disney, Netflix… So launching an app with the mere possibility to play and pause video wouldn’t make any sense on the market. At the same time, there is a need for people working on a product to receive feedback as soon, and as often as possible. Here the MVP jumps into a play. Through MVP, the product manager and the team can decide what is minimal that could be shown to important people to receive feedback.
Defining MMP will be significantly impacted by the estimates of complexity of our product. This assumes that we have to have some, at least, high-level estimates on how much our products will “cost”. With this in mind we will be able to fine tune the MMP, to include only what is really necessary in the first release, while other features will be planned for later releases.

8. The visual design

All previously described steps bear tons of dilemmas and confronted opinions on how they should be done and what they should include, but this step has a controversy highly embedded in itself. There are significant differences between product people in approach to when the visual design of the product should be delivered. You might push it as close as possible to the ideation phase, but there are also reasons to push it as much as possible to the later phases of the product discovery.
I would say that this depends, among other things, on how you have organized teams and work processes in your organization. If you don’t have a product trio as a body to drive the product through the discovery (and also through delivery), then it makes sense to postpone development of final visual design (pixel perfect) to later stages. On the other hand, if a designer is incorporated through the whole discovery process, you will have some design drafts from early beginnings.
My view on this is that at the end of discovery, you have to have at least high-level design, on the level of wireframes. The reason for this is that you can discuss the future product with the development team in more detail. Developers don’t need pixel perfect design to understand what should be built, or to give some assumptions on the complexity of the task that should be done. For these purposes, wireframes will do just fine. Yes, it would be better if we would have the final design, so that we know all the details on user interactions, but if this means that, due to organizational or personal reasons, we have to wait too long for the design, then the lost time is not worth this piece of information.

With this we conclude the discovery phase. In a nutshell, the deliverable of product discovery should be clear understanding of what we want to do, described in just enough details that engineers can start wrapping their heads around concrete execution problems, i.e. going into technical details and start providing answers to the “How will we do it?” question.

9. Next steps

So, what comes next? Once the discovery part is finished we are entering the delivery phase. This means that we have to prepare for the development. In order to do that we need to communicate the discovery results (or, the what we are building) to the rest of the organization. Good way to do this, and to include a wider audience, is organizing so-called User Story Writing Workshops. After which we should be engaged in some sort of delivery planning, be it release planning event, or some other, less formal event, after which we are entering in the delivery phase.

As said before, once in delivery it doesn’t mean that we forget about discovery. Firstly, through delivery we constantly receive feedback on what we are building. This comes from the team, system architect, designers, other product people, but also from stakeholders during demos of our work in progress.

Secondly, while in delivery for one feature, we are working on discovery of new features that will come to be delivered in a week, month or a quartal.

 

The Design Sprint A Way To Solve Business Problems

Author: Predrag Rajković

You want more customers, the next cool feature, a service tailored to your customers? The Design Sprint can help you address those challenges. Find out what it is, what you need to run it and who can help you do it.

When it comes to product design, one can hear challenges product teams meet: ”My team is stuck in the process and needs help to proceed with feature productization.”, “We are too slow coming from idea to ready-for-development phase.”, “We have a challenge in making the decisions regarding product design. We keep discussing, but reaching the decision is almost impossible!”.

These are just a few examples product teams and product managers meet while managing their products.

A framework, or a collection of applied techniques called The Design Sprint can be used to overcome those predicaments.

The Design Sprint originates from Google Ventures, and has been developed from their work and understanding of start-ups, to help them pass the journey from idea to concrete product validated by end users[1]. As defined in the book that explains it, the Design Sprint[2] is a framework used by teams of different sizes to solve and test design challenges in 2-5 days.

Put like this it might sound very broad and doesn’t provide understanding when, how or why it should be used.

Let’s try to answer these basic questions.

What is the Design Sprint?

As indicated above, the Design Sprint is a framework, or a collection of techniques that can help teams in solving business critical issues. It is most often connected to product teams solving product design problems, but it can be successfully used for creating services, marketing campaigns, even processes.

This framework helps teams take the journey from problem definition, setting the long-term goal, ideation, proposing possible solution, its prototyping and finally testing the solution with end users in 2-5 days.

This means that once you face the business challenge, you need to engage your team of 5-7 persons for 5 days to come to a validated solution of the problem.

Sounds great, almost too good to be true, that in just 5 days you can see the possible solution of the most important challenge your company meets today.

But, let’s look at the second question, when does it make sense to use the Design Sprint.

When can it be used?

First of all you need to have a serious challenge in front of you. You won’t engage your team for 5 full consecutive days just to solve whether your call to action button should be positioned slightly left or slightly right. You want to engage people around something significant, something that may impact your business or that requires potential significant investments and something that is surrounded with certain uncertainty. In other words, you’ll want to run the Design Sprint when:

  • Your company has to make a decision that will cause significant investments in the future
  • You are creating new product
  • You want to improve important part of your existing product
  • You want to get alignment in the company around something where company is stuck
  • You have an idea that you want to pitch to your management

Who is using it?

Although the framework started from working with start-ups it has been adopted by a great number of big companies from different industries. Let’s name a few: Google, Lego, United Nations, Deutsche Telekom, Ikea, H&M, KLM, The New York Times…

It is interesting to mention that McKinsey are offering this framework in a set of their services, but under the name of Concept Sprint.

Does this make sense? Give us a call and schedule a chat with our coach, a certified Design Sprint facilitator to get more details.

What does the process look like?

Before starting running the Design Sprint you have to prepare yourself and the sprint. What you need is:

  • Proper and significant problem that should be solved.
  • A facilitator to lead the team through the Sprint
  • The decider to make important decisions during the Sprint
  • The team of 5-7 people to do it
  • Space, materials, stationeries…

Originally, by the book, the Design Sprint takes five working days Monday to Friday.

The source: https://www.invisionapp.com/inside-design/design-sprint-2/

However, depending on the problem that is to be solved, level of uncertainty around it, how much work has already been done, team experience it can be done in less than that.

As a matter of fact, back in 2018 the Sprint 2.0 was introduced which shortens the time needed for the Sprint to four days, and requires the full sprint team to be available only for 2 days instead of 5. This shortening has been achieved through focusing some of the activities, while at the same time, the implementation in numerous cases has shown that other activities don’t require as much time as it has been initially envisaged.

The source: https://www.invisionapp.com/inside-design/design-sprint-2/

However, for the purposes of this article and simplicity of explanation, let’s assume a full five days is needed.

Monday – the first day of the sprint is the day where the team gets on the same level of understanding of the problem to be solved. Here everything known about the problem is put in front of the team. The decision on the goal, where we want to be in 1-2 years time is made, and this decision is something that will be our North Star throughout the Sprint.

The map of a user journey through our product is made and the decision upon where in the journey we will focus for this sprint is made.

On Tuesday the creative work happens. Interchanging group and individual activities bring us to different proposals of possible solutions. The solution creation is done individually, even more, all solutions are kept anonymous in order to avoid idea pitching, or choosing the solution because someone in particular made it, not because the team believes it is the best one.

Wednesday is the day for choosing the solution that will be prototyped. The solutions created on Tuesday are all pitched by the facilitator in order to provide the same and unbiased voice that will represent them. The team chooses their favourite, and the decider gives their opinion on what should be prototyped. The fact that a certain solution has not been chosen doesn’t mean it is wasted. All good ideas are being parked, and they can be used later should this be found suitable.

Thursday is a prototyping day. Here the team has to make a rough representation of their idea. The prototype should be quick and ugly. There are at least two good reasons for this:

  1. The team should not spend too much time on something that is just a concept that is to be tested;
  2. The prototype should clearly show to interviewees that not too much effort has been put into it. This makes it easier for them to give sincere feedback without feeling bad if it is not all sunshine and rainbows.

Finally, Friday is the day when the solution concept is validated with end users, and the day where the energy, tension and team expectations hit their maximum!

One team member is going to lead the interviews with end users, while the others will, via camera, listen, watch and take notes in another room. For this kind of validation 5 interviewees is enough as very quickly the main patterns in user feedback start to show.

Once this is done, what you have is a worked-through idea of a solution, tested with users and a collection of valuable user feedback that clearly points where and how to develop your product further on.

Of course, this is not the end of the product development process, but at this point main issues have been solved and main uncertainties removed.

What are the main benefits of using it?

There are numerous benefits of using the Design Sprint. Let’s name a few.

  • Increase speed of discovery and delivery
  • Saves money by helping fact-based decisions
  • Reduces the risk and uncertainty
  • Shorten discussions and alignments in productization phase
  • Provides unbiased language for strategic discussions
  • Fosters data driven decision making

The Design Sprint also has certain advantages over other techniques used in similar situations (brainstorming or workshops for example). Firstly, as all proposals and ideas are anonymous, the Design Sprint evades situations in which a solution of the loudest, or highest paid person is chosen over solutions that might be better, but the creator is not loud, pushy or influential enough to push them through.

Another thing is that nothing created in the sprint is wasted. If a certain idea is not prototyped and the team finds it interesting, another Design Sprint can be run, and this idea can be prototyped and tested in this new sprint.

How to sell it to your boss?

The crucial thing in running the Design Sprint in your organisation is to “sell” it to your management. Apart from educating them about the Design Sprint and its benefits, there are several things more that you can do.

Prepare main stakeholder (the Boss)

  • Position first Design Sprint as an experiment
  • Show case studies
  • Perform a short version of the Design Sprint to showcase its effectiveness

Prepare other stakeholders

  • Workshop to onboard stakeholders

Just run it!

To conclude, should you have a business problem that needs to be solved, or an important decision that has to be made where alignment of different stakeholders has to be achieved, the Design Sprint can help you. Find an experienced facilitator to help you lead you through the process, and start sprinting!

A lot has been said about this framework, but the best way to understand it is to run it. Only through real-life engagement can you feel all challenges and find ways to overcome them. Satisfaction with the result of each sprint personally, but also energy created in the sprint team is something that is really priceless.

 

[1] The same term is used in another context by Jeff Gothelf and Josh Seiden in their book Lean UX, Applying Lean Principles to Improve User Experience, as a sprint during which the visual design of a certain feature is solved. This sprint happens before the development sprint and provides sufficient information on the feature that will be developed during the development sprint.

[2] Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days,  Jake Knapp, John Zeratsky, Braden Kowitz, 2016

 

The MatchAbout Project: A Journey Through the Software Product Development Process

Before we begin, I want to note that this text will be lengthy and will cover the entire process from idea to market launch. I aim to provide a comprehensive understanding of the vast difference between the world of software coding, which is undertaken by thousands of software companies, and software product development, which is only done by few of them.

I will describe the process of our thinking, the problems we encountered, and the solutions we came up with, as well as the steps we took from idea to market. However, this blog will not include any frameworks, techniques, or theoretical parts, such as how to do product discovery or design sprint. Instead, we will provide links to other blogs where you can find more information on these topics.

Product Discovery

The client’s requirements were to create the first social network for events. The idea was based on the assumption that people needed a way to connect before, during, and after business events, and to provide a tool for sales and marketing professionals to increase and measure results at events.

We all know that live business events are crucial for companies to sell their products, raise brand awareness, make connections, find employees, and learn new information. Imagine something like LinkedIn for events.

This concept seemed like a great idea, with the obvious target being companies and businesspeople attending events. To ensure we were on the right track, we conducted a product discovery process with our target companies. Through surveys, we discovered that they were thrilled with the idea of having a sales and marketing tool at business events and the ability to measure results at these events.

During our product discovery process, we also found that only a small percentage of business events are organized by companies, with most events being organized by communities and micro-companies known as event organizers. This posed a challenge before we even started the project – how to solve this issue. Our original idea gives value to companies and participants, but not to event organizers. In order to provide value to them, we needed to figure out how to approach event organizers and encourage them to host their events within our app. After all, without event organizers, there would be no Companies to offer value to!

On that topic, we discovered that event organizers are extremely price-sensitive, and the main issues they face are how to effectively sell their events, register attendees, check them in, sell additional services to sponsors, and make the event enjoyable for all attendees.

It became clear that in order to provide value to companies, which was our initial idea, we needed to first provide value to event organizers.

In collaboration with the client, we conducted research on how event organizers function and analyzed the competition in this field. We didn’t want to create yet another event app that would compete with the hundreds of others that already exist, each with their own agenda, registration, venue information, and white labeling features.

After thorough research, we realized that marketing and sales functions were not the way to go for event organizers, as they were already using EventBrite for that purpose.

Instead, we focused on the fact that event organizers are essentially communities. We decided to offer them the opportunity to run their communities on our app. Moreover, we discovered that event organizers had a significant problem with checking attendees in on time. Every system that they had until then was too slow, requiring them to register people with printers, QR codes, lists, and so on.

We proposed a solution with a self-check-in process that utilized geo-location. This was an idea that we were particularly proud of, and it later proved to be effective when we successfully checked in 500 people in only 15 minutes, which is equivalent to 1.8 seconds per person. We also discovered that event organizers would like to have digital signage which would show the real time content on the big screens on event directly from sponsors and participants. They can sell the feature to Sponsors.

What product discovery discovered

The conclusion drawn from the product discovery process is that the equation for successful events is not a simple one. There are multiple stakeholders involved, all of whom need to be satisfied in order for the product to be successful. It has been decided that the system should have features that satisfy event organizers and are also valuable to companies at the same time.

We quickly realized that this presents a trap that many companies fall into. The creators of a startup are often emotionally attached to their product, and as a result, they may pursue their goals at all costs, without considering the needs of all stakeholders. Therefore, we proposed that we not rush into software development without first understanding the value for all stakeholders.
To define the MVP (Minimal Viable Product) and reduce software development expenses, we suggested using the Design Sprint technique.

MVP (minimal viable product) and Design Sprint

Before beginning our design sprint, we held several brainstorming sessions where we discussed our assumptions and surveys from product discovery to arrive at the idea for our minimum viable product (MVP). To ensure that everyone from the business team was prepared for the session and that we stayed on track, we time-boxed the discussions. While these sessions were fun, it was important to maintain structure and ensure that everyone was well-informed about the topic; otherwise, it would have been chaos instead of brainstorming.

With a list of desired functionalities in hand, we began our design sprint using Figma for prototyping. We created an app that could be run on a phone, allowing us to click on each functionality. These functionalities were not yet connected to any logic or database; instead, they were mocked and returned some dummy data.

On the last day of our design sprint, we interviewed around 15 members of our target group (companies and event organizers), showing them the parts of the app that were tailored to their needs. While both groups were generally satisfied with some of the functionalities, others were less valuable to them. We recognized that for the MVP, we needed to give up on some of these functionalities in order to save money for our client.

At the end of design sprint, we had clear vision about what is valuable to the users, how they like first idea of the app design and what are the good and the bad things in first version of UX. These were only guidelines but valuable guidelines for us.

What about Business model?

Ultimately, every product is designed to generate revenue for its owner. The management of MatchAbout knew this from the start, and created a business model centered around marketing and sales tools for companies participating in events. The idea is simple: by providing companies data about other companies attending the event, MatchAbout enables them to prepare beforehand, conduct business during the event, and follow up afterwards.

What about event organizers themselves? The majority of them are micro companies or communities, who are often price sensitive. To accommodate this, MatchAbout has decided to use a freemium pricing model, offering some basic functionalities for free, and more valuable ones for a fee.

You may be wondering why they doesn’t offer everything for free to event organizers. The answer is simple: human nature is like that, if something is free, it is perceived as having no value. If something is solving a problem, it is essential to attach a price tag to it. Remember the feature that someone is able to check-in 500 people in 15 mins? It is a big deal.

And what was the result? MatchAbout has ended up with a business model that has one primary revenue stream coming from companies, and one secondary revenue stream coming from event organizers.

Business people are very creative when the money is in the game. We came up with numerous revenue streams such as ticket sales, ads, digital signage, video streaming… It is crucial that in beginning everything is simple and strait forward. We do not want to make complications for users in MVP.

Architecture and infrastructure

People who create new products often dream that their invention will change the world. This is an excellent motivator that drives the entire team forward with energy. The Matcahbout team, for instance, dreamed of creating a new LinkedIn for events. However, building such a significant product absolutely require the best hardware, latest software architecture, or the latest technologies. Is that right?

Absolutely no.

This section is crucial, and I want to explain it thoroughly. In my 22 years of software product development, I have witnessed many companies fall into this trap, costing them a significant amount of money to rectify.

There are two paths that often lead companies into the trap.

First approach: When a team, particularly a small startup, decides to save money, they may opt to develop a minimum viable product (MVP) for testing the product and the market. To achieve this, they may choose to use cheap shared hosting or servers that host multiple products on the same hardware. Although this approach may be suitable for development, it can be catastrophic for any production release. Sharing resources with many other projects can lead to inconsistent product response times, with periods of good response time followed by periods of extreme slowness.

If you reach out to the hosting provider about these issues, they will likely claim that they are great and suggest that you need to optimize your software. However, this is not true, as they are typically of very poor quality. In reality, they are only suitable for hosting static sites with a few web pages.

On the other hand, when you require from development team to build an MVP to test the product and market, they may create the prototype very quickly. However, they may not consider scalability when designing the architecture and writing the code because this is only prototype.

If you release a product with minimal expenses, using cheap hardware and fast development, and the market indicates that your product is not wanted by users, that can be a great outcome. However, if your product gains traction and users start adopting it, with the user base growing, management happy, and requests for more functionalities, you could be in trouble.

In such a situation, you may find yourself with hardware that cannot support more than a few thousand users, and an architecture and codebase that are not scalable on platforms like AWS or Azure. The only option left is to keep adding more hardware until you reach a limit, and eventually, you will have to rewrite the codebase. This can cause a lot of stress for management, who are anxious about keeping their users satisfied, and for developers, who must cope with the technical complexities of scaling up. I have seen many companies pay a high price to resolve these problems once they occur.

There is one saying: Be careful what you wish, it may happen.

Second approach: This is a common scenario in medium to large companies. They already have a lot of money and want to do everything according to the latest standards. They have the best DevOps experts, software architects, and everything is top-notch. These experts will immediately choose Azure or AWS, create a development environment, staging environment, production environment, and implement the best security measures and products. In other words, they purchase everything money can buy. The software developers will suggest using microservices, the latest technologies, the newest frameworks, building the web app in one tech stack and the admin part in another, and of course, developing native IOS and Native Android apps, as hybrids are not providing a satisfying user experience.

These actions can result in a project that requires 8-12 people instead of 3-5 people, leading to slower development, synchronization issues, and significantly higher costs. While this sets the project up for success, if the market rejects the product, a large amount of money has been spent without success. At least the employees are happy, as they have worked with top-notch technology and learned something new.

What is the solution?

There is no silver bullet, but I will explain what we did in the case of MatchAbout.

Infrastructure: We took two dedicated servers with reasonable price and put on them dev environment, prod environment and databases. How, it is a deep tech story which we will explain in some other blog. Is that good solution? Yes and no. Yes, for dev and market test phase, no for product that needs fast scaling. We are now in development phase and we do not have hundred thousand of users and we will not have them in one-year period, so for one year we will save lots of money.

Architecture: This is a critical aspect of the project. We need to design the system in a way that is easy to maintain, allows for fast development, is highly scalable, and can effortlessly transition to AWS or Azure in the future. I won’t delve into the technical details, but we opted for a monolith instead of microservices, which we prepared with loose coupling and multiple projects, allowing for easy migration to microservices with minimal effort. We employed various caching mechanisms to optimize performance at all levels and maintain low development costs during the early stages while enabling quick scaling to larger systems if required in the future.

We decided to use the Ionic framework, which eliminates the need for dedicated IOS, Android, and Angular developers. Instead, we only need one Angular developer to work on all three platforms – IOS, Android, and web. We also selected frameworks and languages that can operate on both Linux and Windows operating systems, providing our client with flexibility and choice in the future.

The conclusion is that we have chose infrastructure with minimum expenses, kept the team as lean as possible in order to have fast communication, but we set the software architecture on such way that the team needs very short time to change dedicated servers to full scalable environments like AWS or Azure. Software will allow that.

We’ll be posting more blogs in the future that will provide in-depth explanations on topics such as AWS, Azure, Native vs. hybrid, and security.

For now, I’ll give a brief overview to avoid being grilled by the tech guys.

Are AWS and Azure good options? The answer is both yes and no. They are excellent for scaling products when you have income that far exceeds expenses. In other words, when your product is on the market and growing rapidly. However, during the initial stages, you may find dedicated server providers that are 8 times faster for less money than AWS and Azure. The downside is that they cannot be scaled as quickly as AWS and Azure. But during this phase, scaling isn’t a major concern.

Microservices are great, but they come with a price: slower development and cumbersome maintenance. You don’t need this for your MVP, but you should be aware that they will be necessary if your product has millions of users in the future. That’s why it’s essential to set up your software architecture in such a way that you can switch relatively easily when the time comes.

Native mobile apps are great, but you don’t need them in this phase. The Ionic framework is built on Angular, so you can write your app in Angular with minimal additions, and you’ll get native apps for both platforms. When we generate enough revenue, we’ll hire IOS and Android developers to do the job properly.

Now the project is set to go really Agile.

During the development process, we used the Scrum framework, as it is well-suited for product development. However, on other projects, we have used different frameworks such as Scrumban, Kanban, Safe, and Less. Additionally, we teach Agile to other companies, so we applied the same approach to this project.

Contrary to common belief, the Agile approach does not require developing an MVP and then testing it on the market. Instead, we can test different parts of the product, including functionalities, UX, and performance, with the help of Innovators. You probably heard that technology adoption lifecycle consists of five groups of people: Innovators, early adopters, early majority, late majority, and laggards. Innovators, in particular, are extremely valuable for products as they can provide us with valuable insights before the MVP is completed.

We create a valuable micro product for Innovators, test it with them, gather feedback, and then iterate again. When we test something, it doesn’t mean that our users have to report bugs. Instead, we provide a complete and beautiful micro product without bugs and kindly ask users to help us build a better product by providing their opinions. By respecting our users and providing them with something useful, we can gather valuable feedback and improve our product accordingly.

The philosophy is simple: we develop, test with Innovators, gather results, do our homework, and iterate again.

Tech that we used: Angular, ngnix, Ionic, java, posgresql

 

Later on, one of our developers expressed interest in trying out .net for a specific functionality that was completely independent. Our management team allowed him to experiment and learn, and he was able to successfully create a microservice on the monolith architecture without any issues. This was proof to us that we were moving in the right direction. After 6 months of development, gathering results, adjusting the UX to users we finally got to the market release, but that is a story of sweat and tears and fight with totally different beast.

To be continued in the next blog…

Outsourcing Business Development Manager

 

Puzzle Software is a team of passionate and dedicated IT and Agile professionals devoted to deliver excellence in software solutions and services. We provide custom software development services, our teams also work on several start-up projects, developing solutions for our clients, adjusted to their needs.

The IT industry is one of the biggest in the world, but the most impressive thing about it is ability to make changes, making everything digital and available for all. From that perspective we started our journey.

We change the world and create virtual not only for the clients, because we work on our own projects, startups created by Puzzle Software. Another tool that we also use to improve software industry and digital products is Agile education and certification, with customized coaching and mentoring programs.

 

After 10 successful years we would like to boost our projects, nurturing our relations with trusted partners as well as with our great consultants. That’s why

 

WE NEED YOU

 

Business Development Manager

 

What do you need to become our SuperHero? The biggest advantage is proven experience in hardware, software, B2B or SaaS sales. Asset could be also proven sales or customer success experience. You should be well-familiar with the IT market and industry in Serbia and Belgrade.

We imagine you as a young or mid-age, ambitious and established person, with the entrepreneurial spirit. You should be a graduate from Faculty or have a bachelor’s degree in relevant subject. Due to frequent traveling you should be an active driver with B driving license.

Speaking about skills, especially soft, it will be of crucial importance to have excellent communication and negotiation skills. Excellent time management and planning skills, with proactive and problem-solving attitude are additional asset.  Knowledge of CRM software and MS Office (MS Excel in particular) are also one of your strong skills.

By personal characteristics you should be extroverted, communicative and witty. You should have strong negotiation and presentation skills, the ability to gather and process information related to market research, emerging trends and analysis of successes and failures. Fluent in English, speaking and writing.

Our team member should be social network influencer, strong in communication with the community. From that perspective you should know IT trends, to be in line with them, and to have strong interaction with the IT community.

 

If everything so far is suitable for you, let us introduce you with some of your main responsibilities You will have to work closely with our CEO and the rest of the team, to develop a growth strategy focused both on, financial gain and customer satisfaction.

Your role will be more human-related, but you should conduct research to identify new markets and customer needs. Regarding administration part, you should arrange business meetings with prospective clients and take leadership role in negotiating and execution of future agreements, same as keep records of sales, revenue, invoices etc.

You will be the face of our company in our business relations, so, you should promote the company’s services addressing or predicting clients’ objectives. Building strong and successful relations, you should provide trustworthy feedback and continuous support to our clients. Also, to build long-term relationships with new and existing clients and stakeholders.

 

This is how we see you, and here we are! Small and friendly team, waiting for you to join us ‍

Why should you become a part of us? We are aware of your value for our team and future development, so we offer a set of attractive benefits. First of all, a job in a small team released of corporate structure, with half less pressure than in a traditional sales team, and self-organization without micromanagement.

You will have amazing developing opportunities in terms of bonuses and learning, improving your career level and personal skills. Above all, an opportunity for a gain in the profit share in the outsourcing branch, same as the ability to work with Offshore clients (USA, Canada) and from Europe.

An attractive benefits’ package is part of our deal, modern workplace, friendly team and warm environment as well!

 

Sounds promising to you? Do not hesitate to contact us, submit your application by email jobs@puzzlesoftware.rs. We are already waiting to meet you! ✅

The month of Innovations – MatchAbout app star of the Decembers events

Every month of the year has its charms and the time that is dedicated for. December was a month of innovation. The way how we achieved it is our tool that has succeeded in bringing together the seemingly incompatible as an official event application – MatchAboout app!

HR Week, Congress for Air Conditioning, Heating and Cooling (KGH), and GamesCon are events from different industries. All they had hundreds of visitors, creative organizers, numerous activations, and of course positive feedback from all participants. The common thing for all these events is the MatchAbout.

HR Week was organized for the first time and brought together the most recognized experts from the HR world. The enviable number of connections and direct messages are exchanged throughout the app, making communication much more efficient. Participants were always fast informed about a change of agenda or logistical data, they shared materials and presentations of the most senior lecturers. With the opportunity of Q&A sessions, posting in a real-time, MatchAbout has shown all its advantages.

KGH (International HVAC&R Congress and Exhibition), on the other hand, is an event that represents a traditional event. With a tradition of over 50 years, it has hosted the most eminent experts in the field of air conditioning, heating, and cooling. Some of the world’s most famous experts in one area have shown they are still very innovative, using most of MatchAbout. Additionally, activations of the whole event were available virtually through Event Wall.

Match About was involved in one fun event – GamesCon, which is the most massive manifestation of gaming and virtual entertainment, and gathers thousands of participants. The organizers of GamesCon have top creative skills, so they had put together fantastic activations that have delighted all participants. Through MatchAbout, visitors used to play, search for treasure, resolve puzzles and win valuable prizes.

As the end of the year is becoming more closer, it’s the right time to sum up our impressions – given the season’s success, Match About has many things to celebrate.

The December’s activities of the Match About started in the spring with the fourth Agile Serbia Conference, that followed by Bizit, Westm, FMGC Summit, and other events. MatchAbout also played the role of the official application on each of these events.

We won’t stop here before the festive atmosphere begins, plans and the schedule for the next season are largely set. If you want your event to be different from others, MatchAbout is your perfect choice, and we look forward to seeing you in the future! 😊

8th Agile Month – Twice more Agile!

The 8th Agile Month has been finished 12th of June 2019, with 4th Agile Serbia Conference. This time, Agile education took three months to be held, April, May & June, that’s why we call it Agile Month Spring!

There were five certified coursesCertified Scrum Master and Certified Product Owner, twice both, in April and May, and Certified Agile Leadership course. Petri Heiramo prepared Agile and Scrum practitioners for their future certification and improved their skills with games and examples from practice, while Olaf Lewitz inspired leaders to become more Agile.

During same period there were five onsite trainings, introducing our reputable clients and their teams with various topics, starting from Introduction to Agile and Scrum, through Scrum Master and Product Owner role to Kanban.

Summary of whole season dedicated work in Agile and Scrum education was Agile Serbia Conference, with its topic – Agile, In & Beyond IT, bringing great tech and business development topics. At the conference were about 600 participants and 13 speakers, Agile and IT experts from all the world. Keynote speaker and star of the conference was Jeff Sutherland, the founder of Scrum! The official app of the conference is MatchAbout, where you can find all the materials from the lectures.

Day before the biggest Agile event in this region – Agile Serbia Conference, Agile Serbia organized PreConference Day, the first event of its kind regarding Agile.  The goal was to provide a chance for all interested to learn more about Agile and to give them opportunity to do that for free!

Next Agile Month Autumn is coming soon, so you may expect the best Agile education as a support of your personal or team’s development for business or organizational improvement.

Retrospective look at our year of 2018!

We are coming to an end of remarkable year in every single view for Puzzle Software, whether we are speaking about software development or Agile field of our business. Our puzzle has really grown this year, so it’s the right moment to do the retrospective of a year, because we’ve done many things to remember!

Let’s start from the beginning. This year we started with new projects, our business portfolio become richer with 2 reputable clients, we made 2 market breakthroughs in this year, with our MatchAbout startup and with USA based company. Furthermore, there are successes with Agile education expressed through courses, trainings and events we organized. Brief overview, but very content year.

There are some significant milestones when it comes to software development field, we are very proud. The first one is our start-up project MatchAbout, is a universal global platform that enables networking from event to event and in between, without any limits, enabling users to collect contacts, materials, and any other valuables from event to event. Designed to boost events activities and to help organizers and stakeholders to find mutual interest, Match About had a premiere this year, even more it was official application at several events: 3rd Agile Serbia Conference, SEE IT Summit, PyCon Balkans 2018 and SuperVoice Talent contest! Still, performance becomes more better and better with every single day, so for the next year we expect real impact on our market and beyond.

The second Puzzle’s precious milestone is our company in USA, based in Fenix, Arizona! We are present at US market since 2015. working on Cloud Migration Consulting and Software Development services. In 2018. we founded our company there, which is the most important step forward for the future and our business plans and development.

When it comes about Agile there are many facts which made this year one of those you have to be proud. Agile Serbia organized 2 Agile Months, in April and November, with 13 certified public courses within this manifestation. Agile education lasted whole year, beside Agile Months, so we organized 15 onsite trainings. According to statistics we had over 400 participants on our courses this year, who came from 11 different countries, not just from SEE region, but Europe and even beyond. The crown of our Agile education work is 3rd Agile Serbia Conference, organized on 27th of April in Belgrade, with the topic “Agile, Leadership & Software Development”. We gathered more than 500 participants from 12 different countries, 20 speakers on 3 stages with Agile Bob as a Conference keynote. This success inspired us to move forward for the next year and to prepare new surprises!

The most important Puzzle’s value are people, our team has grown in 2018. as well, and we intend to stay on that track. Combination of youth and experience join our team during this year, they brought a wealth of knowledge about products and best practices. We have ongoing projects and ideas we are diligently working on it for the next 2019, same as willingness to continue with boosting ideas of our employees.

We look forward to the next year and challenges ahead, all challenges accepted because we strive to create virtual world with plenty of benefits!

7th Agile Month – What to expect in November 2018

We are proud to say that 7th Agile Month is right behind the corner! During this Agile Month, we have five Certified Courses.

For the first time, we are organizing an Advanced Certified Scrum Master Course! A-CSM is an online, guided mentoring and coaching program created by Certified Enterprise Coaches® (CEC) for Scrum Masters and Agile Coaches looking to further develop their knowledge and skills. It’s a 6-week iterative program, where the learning focus is based on your real-life challenges, divided into phases and customized to the needs of experienced Agile practitioners.

Together with our Certified Scrum Trainer, Petri Heiramo, we are organizing Certified Scrum Master Course, Certified Scrum Master Course – Extended and Certified Scrum Product Owner Course. Also, with Agile Coach, Olaf Lewitz, we are organizing Certified Agile Leadership I Course. All the participants will get an internationally recognized certificate, issued by the Scrum Alliance.

In the following Agile Month, we will continue to provide the best education in the field of Agile Development.

[MEET-UP] Architectural Challenges on start-up project – MatchAbout

In Puzzle Software, entrepreneurial and innovative thinking is enhanced and new ideas are encouraged! Since 2014, we have the Start-Up Corner to support start-up projects and currently, we are working on one of them – MatchAbout!

MatchAbout (www.matchabout.com) is an application for networking and engagement at events without any limits. Last month, at the 3rd Agile Serbia Conference, we launched the beta version of MatchAbout app and gained first traction and feedback from the participants. The App was built using Java, Java Script and .Net technologies.

Naturally, we have faced some the challenges building the app. Therefore, we decided to organize a meet-up, and to share with our community challenges that we have encountered. The topic of the meet-up is “Architectural challenges on the start-up project – MatchAbout”. Our intention is to create a discussion among our guests and our development team where we can share the challenges that we have encountered and how we overcame them. Those challenges might be common on similar projects.

The meet-up will be held on the 31st of May 2018 at Puzzle Software.

The meet-up is intended for senior and architect programmers who have experience in Java and .Net technologies. If you are interested in participating, you can send us your details at tamara.vuckovic@puzzlesoftware.rs.  Please note that the number of participants is limited.

Details about the meet-up:

  • Topic of the meet-up: „Architectural Challenges on the start-up project – MatchAbout
  • Target audience: senior and architect programmers with experience in Java and .Net
  • Date & Time: May 31st, 2018, 18:00 p.m.
  • Address: Puzzle Software – Crnotravska 27
  • Contact person: tamara.vuckovic@puzzlesoftware.rs