• 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
5/5 - (2 votes)

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

5/5 - (2 votes)

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