• Home
  • Blog
  • Dobre praktyki wprowadzania nowego produktu IT na rynek.

TECHNOLOGIE, SOFTWARE DEVELOPMENT

20.09.2021 - Przeczytasz w 1 min.

Dobre praktyki wprowadzania nowego produktu IT na rynek.

20.09.2021 - Przeczytasz w 1 min.

Kiedy masz pomysł na produkt lub aplikację, z pewnością staniesz przed wyborem momentu, kiedy pokazać go światu. Z jednej strony chcesz, aby był dopracowany, a z drugiej goni cię czas i poczucie, że przegapisz swój moment. A zatem kiedy jest odpowiedni czas na wdrożenie produktu na rynek?

ADytko_DobrePraktyki_Cover

Wprowadzenie nowego produktu IT na rynek wymaga olbrzymich nakładów pracy oraz odpowiedniego przygotowania.

W tym artykule: 

  • Dlaczego ważne jest szybkie wprowadzenie produktu na rynek?
  • Czym jest iteracja i wartość biznesowa, dostarczana w każdej iteracji?
  • Dlaczego warto zbudować PoC i prototyp 

Dlaczego ważne jest szybkie wprowadzenie produktu na rynek?

Żeby uniknąć utknięcia projektu na kilka lat, najpierw budując wymagania biznesowe, później developując sam produkt bez uprzedniego zderzenia go z rynkiem, należy sprawdzić, czy dany produkt jest realny, opłacalny i czy wybrana grupa docelowa odbiera go pozytywnie.


Szybkie wprowadzenie produktu na rynek pozwoli uniknąć sytuacji, gdy zaproponowane rozwiązanie będzie nieużyteczne lub przestarzałe. 

Czym jest iteracja i wartość biznesowa, dostarczana w każdej iteracji?

 

RST Custom Software MVP

 

W początkowej fazie wprowadzania produktu należy zastosować podejście MVP, czyli Minimum Viable Product. Jest to taki produkt, który spełnia pewną potrzebę biznesową w minimalnym stopniu pod względem jego funkcjonalności.
Twórca Lean Startup, Eric Ries, tak zdefiniował MVP: “minimalnym opłacalnym produktem jest ta wersja nowego produktu, która umożliwia zespołowi zebranie maksymalnej ilości potwierdzonych informacji o klientach przy najmniejszym wysiłku.”

 

Takie podejście pozwala m.in.
– przetestować hipotezy dotyczące produktu przy minimalnych zasobach,
– zminimalizować koszty poniesione w ramach projektu,
– szybsze dostarczenie pierwszej wersji rozwiązania do klientów i pozyskanie feedbacku od nich.

Dlaczego warto zbudować prototyp i PoC?

Co jeśli wizja naszego produktu nie działa, mówiąc kolokwialnie „nie zażarła”, w testowanym przez nas środowisku? Nie złapaliśmy trakcji, a nasz produkt nie ma użytkowników, którzy byliby skłonni z niego korzystać?

W takim przypadku należy zatrzymać się na chwilę i zmienić kierunek, w którym nasz produkt ma zmierzać. Kierunek ten może być określony na podstawie tego, czego nauczyliśmy się już wcześniej od użytkowników i zmienić nasz produkt, dostosowując się do nowej wizji i nowego celu.

Możemy przetestować ostateczny wygląd produktu, na przykład na skrawku jednego wybranego przez nas procesu, wykorzystując do tego dwa podejścia: PoC oraz Prototyp.

 

 

W podejściu pierwszym, czyli przy testowaniu pewnej hipotezy, np. czy wybrana technologia pasuje do tego, co chcemy osiągnąć (mówimy tutaj o podejściu PoC, czyli Proof of Concept), jednostka odpowiedzialna za realizację PoC ma udowodnić możliwość (lub brak możliwości) technicznej realizacji danego rozwiązania oraz możliwość realizacji potrzeb biznesowych.

Jest to w miarę szybkie i tanie rozwiązanie i już po kilku dniach czy tygodniach mamy odpowiedź, czy produkt zmierza w dobrą stronę, czy jednak jesteśmy zmuszeni użyć innego narzędzia albo inaczej to rozwiązać.

 

W podejściu drugim, czyli prototypie, określamy, jaką ścieżkę ma przejść nasz użytkownik, czyli co ma zostać wykonane w ramach kilkutygodniowych prac, tak żeby przetestować na skrawku systemu, jak produkt będzie działać oraz wyglądać.

W późniejszym czasie prototyp można rozwinąć do MVP, podłączając do niego m.in. zewnętrzne systemy, integrując je z kawałkiem aplikacji i w kolejnych iteracjach rozbudować je o funkcjonalności, których użytkownicy potrzebują.

 

Posłuchaj naszego podcastu!

Więcej o wprowadzaniu nowego produktu IT oraz o tym, dlaczego warto zbudować prototyp i PoC usłyszysz w pierwszym odcinku podcastu “Bez prostych odpowiedzi”. Gościem odcinka: ”Dopracowywać czy konfrontować? Czyli o tym, jak wdrażać produkty IT na rynek.” jest Aleksander Dytko – Business Development Executive w RST Software Masters.
Posłuchaj już teraz!

 

Tagi:

Ocena artykułu

Udostępnij

Aleksander Dytko - RST Software

Aleksander Dytko

Business Development Manager

W RST Software Masters jako Business Development Executive pomaga klientom budować i wdrażać aplikacje, które spełniają ich cele. Praktyk Value Based Selling. Koncentruje się na tym, by maksymalnie szybko dostarczać klientom wartość biznesową.

Linkedin

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.